My React-Learning Journey

What is this heresy! :wink:


Well I am a firm believer in minimum state dependency, hence the only occasional and very little need for a state store :wink:

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

@sacha @ffxsam it seems formsy is back with a new release!


I noticed! I’m already in too deep using react-redux-form though. :slight_smile:


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 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!


I strongly second Stephen Grider.