Live data from Hacker News

How I learned to stop worrying and love React

firstdoit.com

101–107 of 107 posts

Re: How I learned to stop worrying and love React

#101

Earlier quoted context omitted.

It essentially combines all of React into a single component, the Reagent atom. It's used exactly like a normal Clojure atom, but whenever it's updated, Reagent will automatically update all Reagent components that depend on it. I find this quite elegant, as it allows one to write pretty much any reactive ui using only three functions: deref, update and render-component. Reagent atoms can even be passed between Cloju…

So Reagent is like React + Baobab ( https://github.com/Yomguithereal/baobab )? Since Clojurescript has to compile to Javascript anyway, I can't think of a reason why Javascript can't have a counterpart to Reagent. I'm not familiar with Clojure, but it seems like atom is the data tree that holds the state of the entire application. If so, could you give an example use case of when you'd pass the data tree between thre…

There doesn't have to be a single atom holding the whole application, that's just an approach some people take.

An example of passing data between threads: imagine a forum that allowed indefinitely nested comments. It also loads comments lazily; one must click to load a comment's child comments, in which case they'll be loaded from the backend. However, if the child comments are minimised again, then expanded again, another backend request won't be made, as the data is already loaded.

I approached this by having a separate 'thread' running that just listened for messages (maps) on a channel. If it was a :get-children message, this thread would check the local cache for the parent comment's ID, and if it found it then it'd add the data to the atom provided in the request, otherwise it would fetch the data, add it to the cache, and then add it to the provided atom.

The comment component would then take a copy of that channel, which it'd pass to its children, and to get comment children data it'd just pass a :get-children message into the channel with an empty atom for the other thread to fill. If a button was clicked that changed a comment somehow, then it could send a :update message through the channel with the parent id, and the other thread would re-fetch the relevant data from the backend.

Of course, there's nothing here that couldn't be done with promises/async. I just personally find Go/Erlang style message passing between threads to be simpler and easier to reason about than async/await, and I believe Reagant/Clojurescript would appeal to others who feel similarly.

Re: How I learned to stop worrying and love React

#102

Earlier quoted context omitted.

To each their own, I guess. I think that any template that's more than 4-5 lines (not including closing tags) is generally a mess and can benefit from being split into more components. AKA the single responsibility principle. Structuring a program with a large number of small components is very awkward when templates and code are in separate files. As far as that 1000 foot view, a nice tree view of React components i…

> Structuring a program with a large number of small components is very awkward when templates and code are in separate files. I agree. We've developed a fairly complex Ember application, and the component hierarchy feels cluttered with everything separated by component and template. E.g. I have /my-component/component and /my-component/template instead of just my-component.js. Its funny coming full circle in MVC app…

You should look at ember pods - it's already built into ember-cli. It basically organizes your project's folder structures live you've described. All 'posts' related items go into a posts folder - its routes, components, templates, controllers, etc.

Re: How I learned to stop worrying and love React

#103
post #74
post #2

Wow, author here. Woke up to a lot of unexpected traffic on the blog. I hope you like this article. I took a long time to understand React and, now I do, I hope other people don't take as long as I did!

Thank you for writing that article. To me, the article is pretty much how an ideal technical article should be: it doesn't assume deep knowledge of the subject matter and uses lots of examples and comparisons to make the case. It takes a lot of work to write that sort of article, I really appreciate that you took the time to do it. Looking forward to seeing the one about Flux!

Thanks for reading! I'm glad you appreciate the effort. I spend an average of eight hours to write one small post (1398 words)!

Re: How I learned to stop worrying and love React

#104
post #67
post #2

Wow, author here. Woke up to a lot of unexpected traffic on the blog. I hope you like this article. I took a long time to understand React and, now I do, I hope other people don't take as long as I did!

I clicked through to a few of your other recommended posts and ended up emailing myself a bunch of links to read later. I particularly enjoyed 'Promises Are Not Optional' ( http://firstdoit.com/promises-are-not-optional/ ) You have a talent for clearly explaining complex abstractions. Nice work!

I don't know about that, but I'm glad you enjoyed it! Thanks :)

Re: How I learned to stop worrying and love React

#105
post #97

For someone whose strong point is not JS, is it a good idea to ignore all other frameworks (like ember, angular etc) and just go with react? I find it easier to evaluate server side frameworks than JS frameworks.

Hey, "first do it", man :)

If you think React could be a good fit, simply use it. Comparing frameworks is very time-consuming and doesn't get you any closer to your goals. Actually, any framework is better than pause-deciding-which! :)

Re: How I learned to stop worrying and love React

#106

I went through something similar...and then I found Mithril ( http://lhorie.github.io/mithril/ ). I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.

Thanks for sharing. I went from Backbone to Angular to Mithril, so it's nice to hear about folks experience with React.

Re: How I learned to stop worrying and love React

#107
post #75
post #66

Earlier quoted context omitted.

Build tool complexity is what I dislike - it's certainly possible, but the trend I dislike is build tooling increasing complexity of the build system of the frontend, decreasing accessibility for onboarding developers. JSX is an unnecessary offender in this department, bringing us farther away from plain HTML.

Have you seen Webpack ( https://webpack.github.io/ )? It's a very powerful tool, but it's quite simple to start with. I can recommend this tutorial: https://webpack.github.io/

Ha, I just realized I posted the same link twice. This is the link to the tutorial: https://github.com/petehunt/webpack-howto
Post reply on HN