Learn What is Special about React/Blaze2

I recently ran into this video which explains a lot about what exactly makes React special. Spoiler alert… it’s not the Virtual DOM or JSX.

Many people believe that React is a paradigm shift in the same way that Backbone was a huge shift from writing messing jQuery apps.

If you have wondered if React is just hype or the real deal, watching this should give you a more informed viewpoint so that you can decide if it’s a fit for you (and your team).

https://www.youtube.com/watch?v=DgVS-zXgMTk

9 Likes

And after you have watched this video also consider to watch other talks from Pete Hunt. :slight_smile:

1 Like

Are there any good intro tutorials for the migration from Blaze to React? I am already watching Sacha’s series, which is great, but did not cover React in particular so far (he began with the transition from IronRouter to FlowRouter, but I’m already there).

2 Likes

Not specifically that I know but in general you want to start at the leaf nodes and work your way up. I just used the React.render in the Blaze rendered callback to insert the React stuff but there are also helpers that you can use now to tidy that up.

If I had a posts list I would try and start at the ‘list’ level and would subscribe to the data and would pass that data to the li item.

Then you can just work upwards until you hit the ‘page’ and eventually use flow-router to render a react page instead of blaze.

This video explains it well. Its the same process but with Reactive data, using the Blaze react helper would ensure it gets re-run if the data changes:

https://www.youtube.com/watch?v=BF58ZJ1ZQxY

I honestly believe that React is one huge trolling.

First, React apostles told us that keeping our JS and HTML in separate files is wrong, because it’s better to organize things when they are together.

Then they told us that we should in fact have two components, a parent one responsible for data and a child one responsible for the view. So we ended up with same two files that we had, but now both with mixed JS and HTML and with additional div wrapper for the outer component.

Makes me wonder what wheel they’re going to reinvent next.

3 Likes

That’s fine, it sounds like you would prefer another view framework. React isn’t for everyone as it makes some opinions. Like I said, the huge shift isn’t JSX, it’s a minor detail. It actually came after React as a thing to make it easier to write (than functions).

First, React apostles told us that keeping our JS and HTML in separate files is wrong, because it’s better to organize things when they are together.

I don’t recall anyone saying it’s wrong, it’s more about efficiency. If you have UI broken up into smaller chunks you’ll have more files. If have JS and HTML files you’re doubling the number of files and making it hard to tell what’s going on with logic. There is also more tabs open in the editor and more file jumping. This is an opinion of the framework. I hated it at first but now prefer it.

Then they told us that we should in fact have two components, a parent one responsible for data and a child one responsible for the view. So we ended up with same two files that we had, but now both with mixed JS and HTML and with additional div wrapper for the outer component.

Again, this is an opinion of the framework and is not necessary. The reason this is suggested is because it separates app specific logic from generic logic. It’s opinions like this that make React a more maintainable solution. You can put all of your code in one file if that’s what makes you happy; for small apps that might be better too.

For example, if an app has a todo list you can make a ‘container’ component that only handles getting the data from the server for that specific use case/page. Then TodoList only has to have logic for laying out the Todos. This means you can use the TodoList anywhere else in the app (or a diff app) and the other instance only needs a different container wrapper to get the data it needs for that use case.

If code golf is your goal, React is not the framework to choose. It’s optimized for maintainability instead of terseness. I wish Blaze was built for maintainability in mind.

Building new features is easy; maintaining features is hard. I think it’s refreshing to see a framework focus on maintainability (and likely this is why I find React a fit for my team).

Makes me wonder what wheel they’re going to reinvent next.

Most likely whatever is making maintaining Facebook difficult, regardless of dogma.