The Aurelia is awesome, but it don't provide the solution for manage state.
I researching a bit and found the two concept of it.
Redux:
https://www.npmjs.com/package/redux-aurelia
It allow us use core concept of redux without extra sugar. In the minimal usable version may looks like that: https://gist.github.com/wegorich/5d1fabc550fb3f01e0a57d3d4308294a
It also more common for most of React apps.
Mobx: https://mobxjs.github.io/mobx/
It also looks good, and the core concept and syntax is more close to the Aurelia one. But I don't find anyone who use it with Aurelia :(
Question:
So the question is what the better way to manage state in the Aurelia application?
Maybe you should consider this article :
http://ilikekillnerds.com/2016/02/shared-state-in-aurelia/
It's appear that Aurelia ( and i m not aurelia dev ) manage singleton and reactive state easily. So, i suggest that : define Store and Reducers immediately without using Redux or MobX.
Maybe ImmutableJS can be very usefull here to define your store ( basically an object ).
And, do not forget, reducers are just pure functions. So, while you know how to write pure functions and you know how to apply to a store , you are fine.
there is an example blog post of using Redux with Aurelia found at sitepoint. https://www.sitepoint.com/managing-state-aurelia-with-redux/
Also there is an aurelia-redux plugin out there which is providing even more support: https://www.npmjs.com/package/aurelia-redux-plugin
Related
Contrast in "apollo-client in next.js" approaches chosen in next-with-apollo npm library and the approach shown in next.js docs.
The link of approach chosen by next.js for apollo client: https://github.com/vercel/next.js/blob/canary/examples/with-apollo/lib/apolloClient.js
In next.js doc approach:
no third-party library next-with-apollo is used
no get-data-from-tree is used
Moreover i found this approach more meaningful and elegant inner-working of client side redering and SSR of apollo-client in next.js. I strongly like this
Some cons in next-with-apollo approach
in next-with-apollo docs, it is stated that in withApollo API, the parameter getDataFromTree of intialState defaults to undefined by implementaion and its stated "It's recommended to never set this prop, otherwise the page will be a lambda without Automatic Static Optimization "
get-initial-props is used which is not recommended by next.js for optimization reasons
general thing. Why to consider third party library if there is non-third party way and suggested officially unless it has drawbacks?
It made me really curious to see many are using next-with-apollo and rarely seen the usage of the approach shown in next.js docs? I'm curious whether approach in next.js docs has any drawbacks (which i strong think of not having any)?
does the approach shown in next.js has some drawbacks?
does next-with-apollo has more efficiencies? if so what r those more efficiencies for which it is wise not to choose next.js doc approach. I wanna be sure that if i'm rejecting next.js doc approach (currently im choosing it) i'm not doing any wrong
So which is better for both client-side data fetching and server-data fetching to support both CSR and SRR?
I found the answer by posting in next.js community:
Here it goes:
next.js doc's apollo examples avoid using getDataFromTree because it traverses the react tree twice in order to trigger all the queries and collect their result afterwards.
The drawback of using the approach on the next.js doc's apollo examples is since you don't use getDataFromTree, you have no way to know which queries your inner components are using. So you need to remember to prefetch everything you need on getStaticProps/getServerSideProps and match the exact same queries/variables
next.js doc's apollo examples way is recommended instead of getInitialProps so I would always use them unless one has some very specific reason not to
As part of the architecture team, we are currently discussing about how frontend should be developped. With the huge amount and versatility of the js framework we have decided to stick on standard as much as possible. So we have decided to use ECMA6 script with web component, fetch api for ajax and polyfills. However, we don't have any data binding for the moment. I was looking for a non intrusive framework that will do the job and found Aurelia very interesting. However, some of us are concerned by the relative heavy weight of the lib(270k+60k for system.js) while we only need data-binding. Is there a way to reduce the size of this lib ? I have noticed there is a data-binding library ? Is it possible to only use that library ? If so how ?
Right, so, if I was simply using Titanium, I could write:
var platino = require("co.lanica.platino");
And I'd be good to go. Since moving to Alloy, I don't know how to replicate the same line in the afforementioned MVC framework.
Do I add it under the global namespace? I already added the module in tiapp.xml, but I have no idea how to access it as a variable "platino".
The docs for Alloy are pretty sparse...any suggestions?
Require method is almost same in Alloy, you can use the require keyword in your js file and implement as in classic approach.
checkout the docs.
I am using redux framework. I am not getting the any values that was I set in redbux framework backend.
It is quite easy to get redux option values.
Suppose test_name is the value of your $opt_name. Then you just need to use $test_name['id'] to access the option value. It's all.
You best head over to the Redux Framework docs. A good starter is the getting started page: http://docs.reduxframework.com/redux-framework/getting-started/
That should get you where you need to go. :)
https://github.com/klaussilveira/neo4j-ogm-bundle
https://github.com/jadell/neo4jphp
I am looking for more stable/ more active and wanted to see if you any one had experience with either one of them?
Neo4jPHP is a simple REST client. You don't get any object mapping from it. If you don't like using ORMs and prefer to do your own querying/lookups, it is probably more your style.
Neo4j-OGM is a wrapper around Neo4jPHP that adds in ORM-type capabilities, annotations on your domain classes and a repository pattern. If you have ever used Doctrine or Propel, you will recognize the style and syntax.
My opinion: if you are used to using an ORM or ODM, go with Neo4j-OGM. If you like to do more tweaking and "bare-metal" optimizations, go with Neo4jPHP.