What is this heresy! 
2 Likes
Well I am a firm believer in minimum state dependency, hence the only occasional and very little need for a state store
Not kidding, I adovocated statalessness on the server side for years (used to be a javaee guy between 1999-2012) and now I advocate the same for client, to the extent possible!
Iâm definitely for only having the state you need, but Iâm interested in how you avoid having a state store in a SPA? Doesnât the state have to go somewhere, either in a single state manager like Redux, or spread out across the app? Or are you favouring the URL to hold the state?
Genuine questions, Iâm still new to web.
MeteorHacks had a good post about this a while back: Meteor UI Pattern: Keeping App State on the URL
Quick quote:
React Flux introduces us a global state manager. I believe they just re-implemented the concept behind the URL.
You could easily achieve fluxâs features by keeping the state in the router.
If youâre a Redux fan though and want to really blend your application state with your URL while preserving Redux goodness, take a look at the react-router-redux project.
1 Like
URL certainly is one place that can keep a small enough state.
But I am not quite fond of the idea of sharing âpersonalâ things âpubliclyâ, as in, app ui state is something specific to a user at a point in time. It may be favorable for sharing, it may not. I think being able to share ui state over a url is to be considered a feature and should not be too invasive.
So, my overall preference is to go with the tools of trade around Meteor. Since we already integrate meteor data, which is something that kind of lives in the tracker context, than the ui state should not be too different. Possible solutions are reactive dict and minimongo and I personally find reactive dict to be quite powerful in terms of a reactive ui state store.
O know there are lots of arguments regarding ui predictability, but hey, are we all of a sudden arguing that UI reactivity is now a bad thing? Have we not had ui predictibality issues with reactivity before and have we not actually solved them all by harnessing the apiâs mindfully?
And regarding the ability to shift from âmeteorâ to âgraphqlâ and betting on âredux/relayâ for a smoother experience, are we not the ones betting on âapolloâ to solve graphql not only for us but for the whole javascript community? Then is it not wiser and more consistent to stick with native meteor apiâs than to diverge over to other apiâs in hopes of converging back in meteor?
1 Like
I noticed! Iâm already in too deep using react-redux-form though. 
2 Likes
This is a very late replyâŚ
I heard on Transmission podcast that Apollo is using redux under the hood. Also I believe redux is tiny. So does it make sense now to depend on redux? Still wondering best solution for forms and whether redux is necessary. New developments/insights?
@vonwao my impression of the react-related stacks since my initial post is more or less the same.
Regarding redux, if you;
- find yourself using this.state too often and some of those or this.props are used for inter-component communication
- keep needing to set up a global state store
- can wrap your head around redux
- are developing more than a todos app
you might actually find it easier to use redux compared to other solutions.
What I do is, start off without redux and add it in as soon as I need my second global state variable.
1 Like
Big update on forms;
If youâre hooked on the ease and power of autoform and its tight integration with simple schema, I suggest you should look at https://github.com/vazco/uniforms which is as powerful as autoform, only much easier to use and customize. It is integrated with simple schema out of box, but can be used without it as well.
And its author @radekmie is insanely responsive to all the issues!
2 Likes
I strongly second Stephen Grider.