I’m about to start a react-meteor project and I’m wondering what the current state of things are?
Any suggestions about what pitfalls to avoid?
Must have packages?
Of course some of this depends on the type of app, but what about your basic must-haves for a react-meteor app? Especially packages where there may (appear) to be no clear “best practice” (based on DLs, etc.)
Simple Schema, Pub-Sub, Methods, Mini-mongo
Can I still use pub/sub, mini-mongo and simple schema without much hassle? Should I invest the time into learning redux?
Anything that still doesn’t work great?
For instance, I know awhile back it seemed like people were having trouble with using accounts-ui login and social oAuth,etc… is this still an issue?
Forms?
I saw nova forms. It seems like there 20 form packages all of which look like they could be abandoned at any minute… as soon as a “winner” looks like it is emerging. I’m not sure I feel like placing a bets on a horse in that race. Am I better off just writing forms from scratch?
Avoid Atmosphere packages at all cost?
Is it a best practice to avoid atmosphere whenever possible? use NPM packages?
Is it possible to use Blaze with React?
I’m porting over an old blaze + 1.2 app and it’d be great to do this in chunks but I’m not sure if that is too much of a hassle?
The most up to date resources/tutorials?
Have you come across any great tutorials/resources lately? Particularly up to date with both meteor and react? Is the meteor guide up to date with react?
Meteor Toys
Does this work with 1.3 yet? Is there a react alternative?
Material Design
I think I’d like a material design feel… any suggestions on libraries that go well with react?
I’m doing similar research. I know React/Redux but am brand new to Meteor. Here’s what I know about your questions.
The only reason that I can think of to add Redux is integrating with a third party API or if you must have global state outside of the pub/sub database. Use React components for local UI state. (Actually, now that you mention forms, redux-form is great, but seems like a lot of overhead for a persistent form)
You can use Blaze with React. For example, I’m in love with Meteor’s authentication library.
Do reactive vars, session vars, and reactive dict play nice with meteor?
I find they come in handy but should i be using props and state instead?
I would really like to use meteor’s account system + meteor.user() etc.
FlowRouter vs React Router? Any Consensus?
Is react router king outside of the meteor world? if so, I wouldn’t mind learning that if it’s a more marketable skill… will that be a nightmare when I could just use FlowRouter with ease?
Reactive components: can use getMeteorData(), react-komposer, TrackerReacy or Tracker.Component - the last one seems like the best option
Routing - I like how ReactRouter makes things concise, just like JSX, and it also seems very active but lacks some FlowRouter features
Atmosphere seems to be getting deprecated by MDG since they are moving to npm eveyrhing
State - setting session variables inside React components would break their pure functional nature so I think using state/props would be better. I also think using MobX to manage state in React seems like a good option
Redux seems like the current hotness but I don’t know how well it integrates with Meteor yet
Material-UI.com seems like the most full feature set of React components, there’s also MDL Lite
SimpleSchema, Pub/sub, methods, mini-mongo has nothing to do with react and still works.
Forms are a bit of an issue. I rolled my own validation and simpleschema connection. Not an autoform, but a quickfield that works pretty well. Planning to publish at some point
Atmosphere for meteorspecific stuff you can’t find on npm. For anything else: npm
Blaze2React packages exist. Allowing you to use for example AutoForm. Check atmosphere
Meteor Toys works wonderfully with 1.3. Blueprint doesn’t work ofc, but everything else seems to work fine on top of React.
Material Design - Not familiar with it. Personally I use React-Bootstrap, which is absolutely epic to work with. So clean JSX I can’t even…
The current app does use autoform heavily. I’ll check it out.
I suppose, ideally, I’d port all autoform forms from my 1.2 + balze app, over to the 1.3 + react app as blaze autoforms… then slowly chip away at moving them to react.
My current concern is that I use FlowRouter. I’d like to use react router— just to get some knowledge with it and for the resume… however I’m a little worried it’ll cause frustration. One person said RR is missing features that FR has.
I was going to suggest somebody sticky this thread (at least for the next 30 days, at which point it’ll probably be out of date again)… but maybe the best thing to do would be to add a new section to the react/meteor guide?
Something titled like “Current State of React-Meteor, last updated MM/DD/YYYY”
This could have a very brief (possibly even bullet points) overview of things… maybe with sections “forms” “router” etc…
It doesn’t have to be super opinionated, or lengthy. Just “hey, these are currently the best practices for this. There are the three or four most popular packages for that. See these few posts for up to date ideas regard [insert]”
Just a section that gives a high-level overview and is easy to edit/update as needed… it’d be easier than everyone having to compile this stuff themsevles by combing through 100 forum threads, or having to investigate meteor guide diffs on github, or having to constantly re-read the entire guide…
It’d also be great if it didnt list EVERYTHING… again it doesn’t need to choose winners, but have some direction. With the form example, I’m not looking for a list of every form package available… but the three or so with the most momentum… even at the cost of hurting some people’s feelings!
Take a look at how unifoms works and you’ll be amazed how easy it would be for you to convert from aldeed:autoform to uniforms, it’s even got almost identical syntax for quickforms!
Regarding FR vs RR, they have different opinions about mounting/nesting layouts and components which may put you off t first. I doubt changing too many things at once would be a good idea. Instead, you can refactor iteratively