How I learned to stop worrying and love React
firstdoit.com
firstdoit.com
So what it eliminates is the need to learn React. Anyone who understands how Clojure atoms work and how to use Hiccup-style HTML templating will be able to use Reagent with almost zero learning curve.
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 threads, and what advantages it has over promises or es7 async/await.
Just to be sure, I'm not questioning the validity of your claims, I'm genuinely curious about how things work in reagent.
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.
Good point; How does one view the resulting react-page anyway? CTRL+U shows <body><script.../></body> no matter what state the SPA is in..
https://chrome.google.com/webstore/detail/react-developer-to...
(This will show you the actual DOM, not the React components... but since you were talking about 'view-source', this might help you too.)
Using the web inspector has been such a massive and continuous boost to my learning/work with webpages and I'm extremely glad to share it with someone it might help.
I'm not sure what you mean. There's nothing in React that would prevent you from making your pages just one huge component. You can split the code any way you like.
JSX is a bit of a weakness IMO - I absolutely rather have templates in separate files to reduce complexity/concerns located in a file. It also adds build tool complexity, which there is too much of in frontend currently.
Otherwise, working in React is generally clean, but one can get that benefit by utilizing ES6 modules in general. React brings a lot of good things to the table, which is probably best exemplified by Angular 2 pulling a lot of ideas from it.
var d = React.DOM;
d.div(null, 'Hello', d.strong(null, 'World'))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 is vastly superior to a wall of text cluttered up by meaningless implementation details like "div".
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 apps, but I find myself frustrated writing 1-5 line templates -- that I have to import. Why can't I just put it in the same file as the component, and have one file? Subjective to be sure, but I'd much prefer React style components in our project.
We've started using it for inline templates in tests, but it should work just great with inline templates for components.
The pods convention you described definitely helps though.
The smallest unit in UI design is a component, and React maps well to that, allowing you to treat components as functions (you can compose, specialize). You'll realize the power of that once you work with real UI designers who understand designing from inside-out as opposed to dumping a PSD mock of the entire page.
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.
All I really want is an easy way to get performant DOM manipulations. With React I have to build the whole view around the component system, which isn't so flexible. Am I right in thinking that Mithril allows you to put the view together any way you want, as long as the end result is an object it can diff into the DOM?
It's not ideal for all use cases. But for updating the DOM based on changes to the data, I find it to be a useful option.
Square built and fast library on top of D3 called Crossfilter. Speed is pretty amazing when you see the data source. http://square.github.io/crossfilter/
That's correct. Virtual DOM nodes are plain JS objects with `tag`, `attr` and `children` attributes (the last two being optional).
The `m()` helper gives you some sugar on top of that.
Idiomatic Mithril view code, however, is more about declaratively generating vDOM nodes based on a model and/or a view model than, say, jQuery-style DOM manipulations...
You can use the same approach for other libraries:
Add a function as `config` attribute to your virtual DOM element. That function gets the real DOM element as a parameter, and you can act on it with third party libraries.
Mithril didn't quite have everything we needed, though, so we made a small wrapper that provides nicer templating, event delegation, etc.: https://github.com/dailymuse/mithril-coat
I was wondering if anyone had tried both Mithril as well as Deku(https://github.com/segmentio/deku) who would like to share their experience?
Why is a low learning curve important? Several reasons. If you're a developer, it's not a huge investment to learn (how difficult was it to learn backbone / angular / ember?). If you're a startup / company, you don't need to look for X developers, where X is a difficult-to-pick-up JavaScript framework. You also save money by having a shorter on-boarding period for those non-X developers.
I've worked in a hackathon group that picked Mithril up and created amazing results with it right away. I teach at a coding school, and by far Mithril has been the easiest JS framework for my students to learn and work with. For being so powerful, Mithril is quite easy to get started with – and that means a lot.
You have a talent for clearly explaining complex abstractions. Nice work!
The separation of the view and logic is an arbitrary separation that isn't always efficient. It's like owning a bunch of power tools and organizing by color instead of by function.
Templates have components like search bars and login forms and they have logic related to those components. Why should component logic and template code be separated when both the logic and template components serve the same function? Code should be organized by segregating things into widgets. This, to me, makes more sense.
I think the only thing missing from React is the ability to incorporate local css styles into the widget. Again like I said if there are styles associated exclusively with a widget, there's no point in segregating styles into some separate css file.
Logic, structure, and style should be unified and organized by function, not by category.
When the DOM is treated as the source-of-truth for the page's information, the synchronously-visible changes are very useful. However, getting away from treating the DOM as the source-of-truth, which React forces you to do, gets you a lot of power as changes to the DOM can be batched more efficiently automatically.
I still find the structure of an angular app a lot easier to grasp, it might be that I'm used to it but I remember the first time using Angular that it all made sense to me. I liked it instantly. Coming from Backbone, it certainly was a breath of fresh air. I can't say the same thing about React. Sure it's faster, and if you think your app is going to mutate into something big, consider using it. But I personally wouldn't make it my default choice.
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! :)
On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome.
var R = React.createElement
You can inline eqivalent JavaScript statements in JSX, without typical template language limitations in terms of allowed expressions or scope:
{this.props.foo > 5 && <div>...</div>}
{this.props.foos.map(foo => <div>{foo}</div>)} <ol className="Items__list" start={page.startIndex + 1}>
{this.renderItems(page.startIndex, page.endIndex)}
</ol>Maybe JS developers should go through it, through this circle of hell, to avoid it in future, so JSX is necessary evil.
//despite of that, I sincerely thankful for people behind React, for their new ideas and how they changed fields of JS frameworks and mobile apps. Big respect!
Logic and representation are not two unrelated pieces to keep them separate.
//You can use "they" to replace "he/she".
Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic.
It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views.
The notions of logic, controllers, models, storage, and all that jazz are why there's also Flux (or Backbone or whatever else it is you want to use; we use Flummox, it's fine).
That's been one of my favorite things about working with React: it actually works to design bottom-up, factoring low-level components out and then moving them around like cutouts.
I could not do things like that in Knockout, or, god forbid, Mustache and server-side templates; not without changing the application logic to account for the move.
I was making a simpler point, though.
Some of the reactions I see to React seem to come from the notion that it's mixing application logic with view logic. That's an easy misconception to get from reading the tutorials and quick-start documentation: after all, it's using raw Javascript to generate HTML, which is the same language other frameworks use for application logic.
The misconception comes I think from comparing React to Angular. Angular is an application framework. React is solely a view framework. It happens that React uses Javascript --- which works amazingly well in practice! --- to express views. But that doesn't mean it's mixing application logic and view logic.
That's all I was saying. The semantic argument between "components" and "HTML" is totally uninteresting to me. The important point, regarding ease of moving "bits of UI" around, is that React makes it astonishingly easy to do that. It's one of the selling points of React.
It's the example from "JSX in Depth" (https://facebook.github.io/react/docs/jsx-in-depth.html)
// Input (JSX):
var content = <Container>{window.isLoggedIn ? <Nav /> : <Login />}</Container>;
// Output (JS):
var content = React.createElement(
Container,
null,
window.isLoggedIn ? React.createElement(Nav) : React.createElement(Login) );
JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail.
Finally, it's all declarative since you're never modifying a DOM tree - and declarative is a pre-requisite for good UI frameworks.
Especially not if you make an alias to ce or something like that.