My React-Learning Journey

What started out as a short answer to a “what resources did you use for learning React” question on the meteor mentor slack channel, ended up as a post of its own. Now since that I am not a blogger - I really don’t have a blog - I’ll post it here where I think it will be of better use, in the right context:

First of all, I must admit that I’ve been on top of all the news, developments and blog posts since React first ever hit Meteor, so it is fair to say that I have never been a total newbie.

So I guess I should first say that if you ever intend to learn something, begin following the news on that topic. Even quickly skimming through discussions and blog posts will amount to “some level of subconscious understanding” of that topic.

Anyway, about a week ago, I delivered a huge project and had this one-week gap before taking on another fairly large one, with which I’ve already decided to go the React route.

So here’s another word of wisdom, make sure you have a project that you have the opportunity to apply that newly acquired knowledge on. Otherwise everything you’ll think you’ve learned will have vanished into thin air.

I had been “informally” using ES2015 so I also wanted to take this opportunity to formalize my knowledge of that topic as well. And also sprinkle in some npm, babelrc, webpack as well as a pinch of react-css-land.

I must say that everyone has a different learning style. I like having multiple api docs and tutorials open at the same time and jumping around. Since they all touch similar topics, concentrating more on different aspects, it also happens to be a great opportunity to see different takes on doing the same thing.

So, apart from great forum and blog posts, comments, boilerplates, example apps and packages from people like @abhiaiyer, @arunoda, @ffxsam, @gadicc, @joshowens, @sacha, @skinnygeek1010, @timbrandin, @tomredox ; what did I “formally” read and watch? Here’s a list:

If you were crushed on time and wanted a very straightforward learning material, without too advanced stuff, but not something too simple, I’d suggest you go with the Level Up Tutorials videos.

Now there are a couple of things you’ll need to decide for yourself, perhaps depending on the project you’re going to implement React with

  • Which router? Flow Router is easier if you are already used to it. But React Router is the broader standard. Not too hard to switch from one to the other.

  • Do you need redux? Well, if you have complex UI state and lots of interactions between different components or UI actions affecting multiple components, it may make your life easier in the long run. Otherwise, the good old Tracker is still good and not that old.

  • Do you need Mantra? Well, if you have a component-heavy app and especially multiple developers working on different parts of the app, while you think you may need to switch out backends or backend integration layers down the road, Mantra is a great “discipline” to follow. Discipline being the operative word. I find myself disciplined enough to come up with and stick to a set of patterns that make most sense for a given project and Mantra makes a lot of sense for those cases I’ve described, but feels like overhead for others.

  • How do you integrate with Meteor Data? The guide proposes the createContainer method which is very similar to react-komposer so you could use either one. React-komposer would make more sense in a Mantra app. Trackerreact and Tracker.Component on the hand feel more like “home” which you can probably use very safely. They have very simple implementations, so go check out their sources to gain a better understanding of how one can integrate Meteor’s reactive sources with plain React.

  • Forms and data grids? I stil have not found the solutions that best fit my requirements. I need something that can make me feel I no longer want to get back to autoform and tabular. There are lots of alternatives out there and they all have their pros and cons, so I guess you should do your own research on this front.

  • What about CSS? Well, don’t be tricked into letting javascript handle CSS for you or inline styles being the new way of doint things. You can do those things, use libraries to make that easier, but don’t forget that your current grasp of CSS is in no way defunct! Do what you’ve always been doing, trying to concentrate on modularity, and then you can use the newer tools as you think you’ll benefit from them.

  • How do you make Blaze and React play well together? Well that’s easy. You can use Blaze templates within React and render React components within Blaze templates, or mix and match within your javascript code. It is really fairly easy because in the end they end up using Blaze.render() and ReactDom.render(). There are a few packages on Atmosphere that expose those API’s in the form of {{>React}} and <Blaze/> and you can pick any one you like.

  • Do you need webpack? No! But if you already make heavy use of build tools and bundlers, you may want to “upgrade” to webpack because that seems like the way forward. But you can live without it, not even noticing its absence.

I should also once more remind you that although I have familiarized myself with React concepts over the course of the past 6+ months, I’m only into the first week of my formal learning and I am yet to begin a React project only next week. So some of those opinions are likely to change.

Finally, I am a firm believer of learning by teaching. So if you have a question regarding React in Meteor, given that you are also willing to do do some research and experimentation, just shoot! Even if I don’t have an immediate answer for you, I will do my homework to get an answer and we’ll both have learned something new!


Great write up @serkandurusoy! One more important link for all React newcomers:


Thank you for the wrap-up Serkan. Next question is: Blaze or React. :wink:



Oh yeah, that’s a good one! :slight_smile:


Next question is: Blaze or React.

Well, I think jsx kind of helps organizing code, no more back and forth html and javascript, I like being abel to see and work with them together. And IDE (I use Webstorm) autocompletion is so much better with JSX.

And although Blaze/Spacebars is fully capable of components and containers, it is just second nature to it. With React, the paradigm is what the whole thing is built upon.

I also like that React is just javascript and does not introduce any new DSL notation to learn. You know Javascript? Cool, then you know React! It is just like any other library out there.

But then, the “package ecosystem” is what can tip the scale here. With Atmosphere and especially autoform/tabular, I find Blaze more powerful in certain type of apps, namely “Line of Business” apps. But @tomRedox is doing a great job pushing React forward on that front.

Finally, Blaze/spacebars is easier to grasp for beginners and designers.

And although there’s a lot of hype around how much React is superior to Blaze, I don’t think it has merit to the kinds and sophistication levels of the apps that newcomers/designers will be developing.

And Blaze/React can live together as well. So unless we are squeezing milliseconds out of app response times, there’s not much argument against it either.

So, the final word would be, whichever one you find easier to learn and grasp, use that one. You won’t have made a mistake. At least, you won’t have made a mistake that actually matters to your usecase.


Thanks @serkandurusoy for the awesome and well balanced write-up.

1 Like

Thanks for the great write up and the links you listed!

1 Like

Great write-up, Serkand! I also recommend looking at Udemy courses too, they’ve helped me quite a bit. Stephen Grider’s courses are excellent, he’s very good at explaining very technical things.

For those interested, check out my Meteor 1.3 + React boilerplate which contains a very heavily commented example app which serves as a learning resource. I plan on updating it in the near future.


Thanks for the mention Serkand. I got more content for everyone coming soon :slight_smile:

1 Like


For those interested, check out my Meteor 1.3 + React boilerplate2 which contains a very heavily commented example app which serves as a learning resource. I plan on updating it in the near future.

Yes I indeed attest to the comment-quality for that boilerplate. It is almost a document/tutorial by itself!

1 Like

I started work on a replacement for Tabular:

I haven’t had much time to update it recently but maybe it can serve as a starting point?

For forms there’s

Although personally I ended up building my own Autoform-like solution in the form of a very lightweight wrapper around Formsy:

And finally, the last piece of the puzzle, user accounts:


Meteor Griddle looks like it may be able to solve my datagrid issues! Anything worth mentioning? Like any shortcomings, problems, gotchas?

I also wonder what your “autoform-like” solultion looks like. Could you elaborate?

As for accounts, I had never used an accounts ui package, not even in Blaze. I find using the raw accounts api more liberating in terms of custom configurations.

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):


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


Hmm very straight forward indeed! Thank you for sharing this.

@sacha quick question; why formsy out of all the options out there?

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 :slight_smile:

@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?


@ffxsam I agree with @sacha on this one. What about apps that don’t use redux?

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.