Update: @timbrandin’s tracker-component is quickly growing on me as my choice of meteor-data-integration.
1 Like
Not really shortcomings, it’s more that I haven’t tested it with the latest 1.3 release, and there’s a couple pending issues.
And here’s my autoform-like solution (although I’ve decided to move it back inside Telescope from now on):
2 Likes
@sacha - see the following (I submitted a small pull request a little bit ago to get it working with 1.3). Thanks for putting the package together!
2 Likes
Hmm very straight forward indeed! Thank you for sharing this.
I too was using formsy until it appears that it’s been abandoned. I’m now using react-redux-form and really like it.
@hwillson thanks for the PR! I’ve added you to the repo in case you ever want to pitch in more 
@serkandurusoy Formsy seemed like the most popular form library for React, I didn’t know it had been abandoned. Redux-Form does seem interesting, I just haven’t really dived into Redux yet and I’m not sure if it makes sense to only use it for forms if your app itself is not Redux’d?
4 Likes
I’ve found multiple complex forms a total pain in React. Sure, you can manage the field values with React state, but when it comes to tracking various other state data (is this field touched? Focused? Valid? If it’s required, is it filled out? etc etc)? Redux really helps with this, I’ve found, as well as managing the rest of my UI state.
4 Likes
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.