First I love the design of this website. I haven't seen a blog that was so simple and easy to read (hacker news style)... ALSO be this pretty.
Also I'm curious what podcasts you were listening to? Has anyone picked up a new language from listening to a podcast. I can't imagine getting much out of it without the visuals to go with it.
create-react-app is awesome and huge time saver but as soon as you have to step outside of that realm there are so many dependencies and other tools to get the sausage made that it's daunting for new-comers.
It's not at all fair to compare JS and Go BUT that is the one part of Go I really, really love- `go fmt` is built in and most of the tooling Just Works™ with minimal config (e.g. gometalinter). I find myself stuck when figuring out where the next piece of the JS puzzle should go in my local dev at times and how to make some other things production ready. But we're in a much better place now than we have been!
I don't get what the benefit of using React is, aside from having it on my resume. A virtual DOM? What does that get me? It renders faster? Rendering speed is not a problem my CRUD screens have. Etc., etc.
Perhaps some UIs are so complex and dynamic that they're easier to build and maintain using React. I'm not saying other people shouldn't use React, but I'm fairly certain it wouldn't give me enough payback to justify the investment it requires.
Even if you don’t need it for its speed, it’s a fine choice if only to use JSX for your templating.
Aside from that, it and a handful of other technologies (webpack, maybe redux) seem to be coming out ahead as industry standard for SPAs. So yes, learn it “for your resume”, or as I like to put it, “staying employable”.
Edit: this is assuming you already have a SPA based CRUD app. If you are rendering server side then by all means keep doing that.
Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place.
I'm currently still on Angular 1 at work. We migrated to 1.6, where they introduced Angular.component(). It's actually very nice, since it allows for explicit I/O and enforces isolate scopes. It's actually made Angular 1 enjoyable for me.
Not sure what you're trying to say here. Sounds like you don't need React, and that's perfectly fine. I've had applications like that as well. React becomes useful when you have really complex and dynamic websites, not when you're building basic CRUD todo applications.
Sorry, was not meant to be dismissive, maybe the "basic" and "todo" was too much. Basically, unless you need dynamic elements on a page, you're better off without JavaScript. If you have lots of them, React might help.
You can do a fairly complex system by yourself with a simpler scheme because you have a mental model of how things are organized. It's when you throw more developers into the mix that you run into issues.
>You can do a fairly complex system by yourself with a simpler scheme because you have a mental model of how things are organized. It's when you throw more developers into the mix that you run into issues.
I think that's a fair point. And I think others have remarked that it illustrates Conway's Law.[1] For a front end like Facebook's, that has numerous moving parts, developed by different teams scattered all over the world, and those parts have to fit together and work together in combinations that may not even be foreseeable, then a framework like React may be the only possible way it could be successful.
Then don't use react if you don't need/want to. However, it certainly makes many things easier for development for complex applications especially on greenfield projects.
It's frontend technology that is robust enough to deliver Facebook. If you haven't worked on or aren't working on a complex UI with a team of developers, you might not appreciate how incredibly solid React is. This isn't something that can be explained well through anecdotes, but this comment is getting at it:
> Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place.
The complicated web issue isn't peculiar to Angular. Many UI frameworks are modeled in such a way that they become a rats' nest of objects, events, etc. all firing back and forth. Using React with good practices enable an overall structure that mitigates that tremendously.
Actually, I find the DOM surprisingly structured for reading and manipulation. This button have one or more events? No problem! Want to see the code in that event, no problem. The DOM is the truth, and you are free to read, understand and modify it as you like.
What is a problem though, is that there is no consensus in the team about how the code should be structured. So everyone creates their own mess.
Oh state management? There is something called observer pattern for that.
Let me add a different point of view. The adoption of React in the world of ClojureScript was pretty much instantaneous and total. I don't think anybody writes ClojureScript webapps in any other way these days. But the way React is used is different: it's used as a smarter mapping from application state to DOM. Clojure and ClojureScript programmers already know how to manage state and limit its spread, React (plus the usually tiny adapter libs) was just a way to efficiently produce DOM renderings of that state.
It fits like a glove. And while it's not all roses, there are fewer friction points it seems than in JavaScript (but then I think JavaScript programmers don't have it easy anyway). Plus, because of the nature of ClojureScript, most articles I read about optimizing React performance do not apply to me, because all the hard work has already been done for me (for example, immutable data structures mean that you can efficiently prevent re-rendering if data hasn't changed).
Anyway, to sum this up with an example that I'm basing my opinion on: PartsBox (https://partsbox.io/) is something I wrote, using React.
For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: https://github.com/Day8/re-frame
One point about libraries: I would recommend starting up with Reagent, as it has a simple and fairly intuitive model, and then moving on to Rum, which allows you to do anything, while being small and elegant.
He didn't even get to the part that I find confusing; the naming of things. componentDidMount? componentWillMount? Wtf is mounting? This isn't a goddamn harddrive. Props? Do you mean properties? or arguments? Wtf is a prop? Reconciliation? Portals? The fuck?
And then, to top it all off, you can't just use React, you need to pair it with a set of other libraries, each with their own set of ridiculous jargon and paradigms.
I honestly think a bunch of very talented Facebook devs got bored and decided to make something complex just so they could keep themselves entertained. And then other developers followed suit because it has cool words that make you sound important and inflate your ego, even though it's doing the same shit the web has been doing for 30 years.
Nah, it solved huge problems in UI for complex projects. One-way data flow, functional component abstraction, virtual DOM, simple & minimal API (11 methods). It encourages componentization in a way that no other framework quite does as nicely. Because the components are one-way, it's trivial to break up a component that has gotten "too big". I mean, a simple react component is:
const HelloPerson = ({ person }) => <div>Hello, {person}</div>;
Honestly I don't know how I learned React. It's not fun at all. Oh sure, the basics of React is not too hard. If you ignore all the outdated examples and code (using var, no JSX, overusing component lifecycle, not using functional components). But then learning Redux, React Router, React JSS, Reselect, Redux Thunk, Webpack, etc., is just terrible. Sure, there are tutorials for each individual library, or maybe even two or three of the libraries at once. But combining all of them and making sure that it's not a total mess of code is like trying to play QWOP with your code. Now that I have everything compartmentalized and understood, it's pretty easy. But getting there is a long long journey.
I've played around with an idea for a tutorial on modern web development that starts with just basic JS DOM fiddling, then introduces various features and techniques as they're needed. So you'd start with just using old school document selectors. But then, as all the getElementByClassName calls become annoying, maybe you'd introduce transpilation, so that you can querySelector with a map/filter. Then, as the updating starts to get hairy, you could introduce a library like React. As state becomes an issue, Redux. But the point would be to start with the basics and build up an understanding of why we need these libraries. And what problems they solve and what problems they don't solve. But of course, the moment anybody writes this tutorial, half of it will become outdated. Ah well.
So don't use Redux, React Router, and Thunks. I don't even know what React JSS is. Use create-react-app's tooling.
Even Redux's author tells people Redux is overused. A pretty big percentage of the value of the flux pattern is just in having an event pubsub system, so if your application is so complicated that you really feel like you need to structure it, you can just use EventEmitter.
I frankly don't understand the popularity of React Router. The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". If you like and grok React Router, use it. But I don't think it's a good idea to push through your resistance to it.
I mean this in a nice way, I'd really appreciate a gist showing how you get the core concept of react-router in 50 lines. It's in a project of mine now and maybe it shouldn't be.
Seems as though React Router has gotten a bit complex because it's abstracted away from the concept of a webpage, such that one can use it in the browser, or React Native (which can be a number of environments).
Of course, I say just buck-up and learn the damn thing, it isn't that complex... earn the "Engineer" in your job title!
Maybe I'm just an out-of-touch neckbeard these days?
Just a small addendum to your post -- you shouldn't use react router for react native, you should use react-navigation for that (https://reactnavigation.org/).
I use react-router for native and there is a react-router-native package. You "shouldn't" listen to randos on the internet when they are demanding what you use or don't use.
React Router v4 is particularly difficult to get used to when compared to earlier versions. While I don't much mind it (I get it working, then I don't need to touch it anymore), it definitely took me some time to wrap my head around it.
So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there.
All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage.
Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is actually confusion about state containers and their uses.
Partly, the fact that React-Router has upgraded so many times in divergent ways in a short amount of time has left many folks with a bad taste in their mouth.
If the router was just "Buck up, learn it, and you're golden" I suspect we wouldn't hear too much hollering about it. Unfortunately, the hassle of using it is so close to clockwork I feel like I should just schedule a week every six months or so for maintenance.
What's the win to keeping up with it? Am I wrong that the problem it's solving is really pretty simple?
I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I wouldn't mind that much except that wrapping a React component around a fragment of HTML is not a problem so difficult that I'd endure compat problems in a dep to solve it.
With the router, it was never a matter of us just deciding to upgrade for the sake of upgrading but rather ending up being painted in a corner with peer dependencies requiring upgrade. Additionally, because we were a micro service / many SPA outfit, we ended up with a dozen or more applications at varying levels of libraries so you had to deal with 2.x, 3.x, and 4.x or just upgrade.
For those of you reading along thinking "This sounds like a dysfunctional environment!" You're right! Imagine having five heads of department, albeit two interim, in a year.
> I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems.
I'm in the middle of building out an internal component library based on `react-bootstrap`,
so that's fun to hear...
Have your issues mostly been upgrades of the library? Or of Bootstrap versions? We internally decided we're just sticking with Bootstrap 3 for the foreseeable future with the hope that it will mean we don't have many issues to deal with.
It's been a long time since I used react-bootstrap. I just stopped using it and wrapped the Bootstrap HTML myself. I wouldn't be surprised if it had settled down.
It's possible react-router has settled down too, but the experience I had of "I can't believe I ever wasted time trying to figure out react-router" after implementing a "router" myself was so powerful that I'm pretty averse to finding out.
> Say, if you keep you containers, reducers, and actions in their own directory trees.
That layout is the biggest reason it took me so long to understand it when my team brought it in.
It goes a bit against the spirit of Redux, but the tutorials really should pair up action and reducer in the same directory, then later explain why the other way is also useful.
It ended up way, way easier to understand and get people in on it, because in the vast majority of cases we don't need multiple reducers listening to the same action.
For the size of the tutorials, it's probably simpler to use a "folder-by-type" structure. But yes, for real apps, I myself have settled on a "folder-by-feature" structure. Note that either approach is completely orthogonal to whether you have multiple reducers listening to the same action.
The tutorial is already trying to explain a lot of concepts that are new to most people, so we try to keep it focused on the meaningful concepts. Throwing in side discussions on folder structures would probably add more confusion at that point in the learning curve.
> so we try to keep it focused on the meaningful concepts.
For me, scattering a single feature across multiple directories makes it far harder to understand what relates to what. It's _less_ meaningful to group by type than by feature, which makes it harder to learn than it should be.
I'm not saying the docs should go into asides about the alternative structures all over, but rather the people promoting Redux should definitely consider whether or not their examples smell more of spaghetti code than they need to be.
I don't currently have time to go revamp the docs and examples myself, but if you'd like to file a PR to rework things, we can definitely take a look at it.
I agree. When you learn React, small examples typically follow folder-by-type but, in larger apps, it becomes apparent this doesn't work.
If you take the recommended path, i.e add redux iff you need it, you've already settled away from folder-by-type. It's natural to organise by feature since you're generally doing it anyway by that point.
Instead of a rework, it might be easier to add a small page on folder structure.
The absolute most important thing in ReactRouter does indeed boil down to what you said, no disagreement. But there are some niceties, if I'm not mistaken.
You want the things in your app that look like links to have some interesting behaviour. They should look like links, they should act like links when right-clicked.... but when left-clicked, they should not actually load the new page. Instead, they should update the History and also trigger the router to reconsider the routing. That's why ReactRouter includes Links and Redirects.
I suspect there's at least one other feature-of-some-utility in it that I can't think of right now. Hmn.
There's also some weird logic around multi-routing, which I suspect is a bug rather than a feature, but maybe there's a sweet use-case. And there's also some weird stuff about not propagating children, which seems like a bug not a feature, but the workaround is easy, and again maybe there's actually a good reason, I dunno.
Anyway, as with what you talked about, this isn't rocket science, you could do it yourself with some work. But if someone follows your advice and thinks that's the end of it, they'll eventually feel some minor pain points.
That said, I honestly can't be bothered to actually properly learn React Router. I think that some company, ideally one specializing in react training, should write better documentation for it.
You have a top-level component whose render function retrieves the current URL, checks it against a bunch of regexes, and based on that decides which "page" to actually render. The regexes capture "parameters" in the URL with capture groups, and they're passed as props.
You also have a few (single-digit) lines of code to wire up the history API so that the back button works.
You have a tiny helper function that uses the history API to directly navigate to a URL inside your application.
You have a tiny Component that renders an <a>...</a> whose onClick calls that helper function.
I'm sure React Router does a lot more than this. I mean, it'd have to, right? It's so complicated. But I don't know what those things are, because until I'm forced to, I'm not going to bother with it.
Similarly: I appreciate flux and think Redux is a reasonable implementation of it, but at this point, after doing a couple applications with it, I'm going to get as far as I can with a simple EventEmitter and hierarchical state before I bring it into a project. For straightforward applications --- really, a pretty big chunk of the apps I see are fundamentally straightforward --- I don't think it's a win.
With respect to Flux/Redux, the Facebook team even stressed when they originally released Flux that it should be used sparingly. It is useful in some circumstances, particularly that which it was originally designed for, but it seems in my experience that it often used, unnecessarily, as a stand in for a controller (in MVC terms) layer.
When React was originally released it was sold only as a view layer that you plug into your application stack. Since no official way of approaching the rest of the stack emerged from Facebook, when Flux was announced it seems that it was taken as the rest of the stack by many.
This is a great talk by Ryan Florence (one of the creators of React Router) where he basically reimplements the basics of the library from scratch: https://www.youtube.com/watch?v=wPJxmZx62gI
You're not wrong for beginners. They shouldn't use all or any of these tools starting out. But when you reach the point where you understand React and you start to reach the limits of React's features, i.e. inline styles isn't cutting it anymore, setState is growing too big and too complex, etc., that's when it starts to get hairy. Because continuing down the path of pure React is painful, but learning all these damn libraries is also painful. That's where a lot of people get lost imo.
Not to mention the times where the codebase predates you. My first experience with React was on a codebase that was pretty horribly managed. Basically a combination of magpie developers and a total lack of understanding of React patterns. When the developers are finding and trying to integrate the next new shiny lib every other week, it becomes a nightmare for any new developers.
I think far more people get lost trying to learn the libraries than grow an app to a size where pure react too painful.
First time I used react I hated it, because everything was done through flux, want to add a field to a form. Now you need to update 4 different files and create 8 methods. Not to mention interacting with non-react components in a react way can be super painful.
It was insane. Second time I dropped all of the libraries. Only used react, and any time I needed to use a non-react component I wrapped it myself, and many times did very unreacty things like use methods to do a lot of interaction.
And I loved it. Everything is so much easier. I can focus on solving the user's problems, and not my react problem.
The apps weren't huge, but they weren't small either. 3 months of work for 3 devs full time.
I had a similar experience with Redux, every event in the app went through redux. Click button > redux event fired > redux updates state > component catches state update > button listener fires.
It is a total nightmare and a horrible use of redux. That is like binding every variable and function to the window object because you have no concept of scope.
> The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes".
This is a pretty common theme for me when considering any react-* library, and I think it says a lot about how nicely React lets you abstract away behavior.
As for Redux, I feel like the payoff has been worth it, especially when adding in the benefits of tooling and middleware. When I learned React for the second time, I did it with Redux out of the gate, and while it did take a while to ramp up, the upside was I was able to see immediately where bugs were occurring (React + Redux DevTools) and didn't have to grok the component lifecycle before getting some data on the page.
Good points. I enjoy VueJS and AngularJS, thought I wouldn't like JSX and React but React and React Native have surprised me. However, Redux looks overblown for most use-cases and takes all the fun out of it.
For some cases you can just do a singleton on your shared data component. So for handling a multi screen form it just looks like export const MultiFormState = new MultiFormData();
Then import {MultiFormState} of course... Very useful. Between that and EventEmitter as you noted you can avoid a lot of extra code in many applications and get your components working well without the bloat and mental overhead.
I have a million LOC windows forms system that going to be ported to the web. I've reviewed React, Angular, Vue, etc. As a beginner, Vue seems the best to me, however, all of the experienced web developers I talk to recommend React. After reviewing the code and walking through tutorials it just seems like overkill and overly complex but I suppose I'm missing something. It's concerning because I need to have our team port a huge code base and am not sold on React but that's what we're starting with. The developers I talk to say Angular is too complicated and React has good component based features. Nobody has Vue experience. My gut tells me Vue would be better but if I can't find guys who actually use that and have React experience instead then it seems that's the direction to head.
Sometimes react ecosystem and all the dependencies feel way too much. Sometimes all I want is to use data bindings, and at those times I just ended up using Vue.
Same here, but in my case when I need that I usually go with Mithril.js[1]. I found it by chance and instantly liked it. It's a shame that nobody seems to know it.
The framework usage is still growing, though it is dwarfed in popularity even by Vue (which is ~60 as large). We do little to promote it, and hyperscript (the default view syntax, i.e.
m('.foo', {...attrs}, ...children)
) is not very popular (even though I prefer it to JSX, which is also supported).
I have a blog. It's a set of static pages, generated offline and served via Nginx. There's nothing dynamic there and the content is perfectly readable in lynx.
Once in a blue moon, I want to add a screenshot or other image to a post. Such images are of various sizes, mostly larger than the (max)width of the content. I use CSS to scale them down to fit with the text, but sometimes images displayed like that are too tiny to be legible. For a long time I handled this case by wrapping <img> with <a>, basically like this:
It works, and I like it, but it has a couple of drawbacks, most important being that it's kind of intrusive - by clicking it, you change the current url, and when you get back, even if your browser scrolls the page correctly, you need to find the place where you stopped reading.
At some point, I gave up and included a bit of JavaScript, which enlarges the image while you stay on the same page. I used some kind of fancybox derivative - a jQuery plugin.
The choice of tooling has to be dictated by actually delivering a product, even if it's open source. If JQuery met your needs at the time, and your personal preferences and experience are nonfunctional requirements, it was the right call. That doesn't mean that in the future you won't grow beyond that, but having to transition a production system to a new technology is fundamentally a good problem to have.
(See CodePen link for code credit. Pretty clever little item, if you don't have to parse the pure markup. Even then it's not overly intrusive.)
Source: I'm currently building out my own Javascript-light blog/cv site, even though I generally like working with React. It's just not needed for everything. I'll likely extend on this at least a bit for some nicer effect with some current Javascript— barring older browsers from the lightbox effect but still able to read the thing in lynx and if need-be.
I recommend the e-book Fullstack React (https://www.fullstackreact.com/) (I have no relationship to these guys, other than being a customer).
I have had junior engineers read it in the past to get up-to-speed and it does a great job of teaching all of those technologies together in a way that makes sense and is easy to understand.
Let me also add that it doesn't teach them all at once. It starts from first principles and adds on new libraries as the tutorial apps become more complex.
I found react to be extremely intuitive and easy to learn. Redux and react-redux are horribly non-intuitive. So much boilerplate and meaningless terminology and stringly-typed objects. I avoid it.
I want to learn Mobx. I like the conceptual model (functional, immutable) of Redux though - I'm just not a fan of all the boilerplate although I understand why it is there.
What's your take on things you miss from Redux now that you've switched over to Mobx?
React is just mapping data to XML, which may or may not end up as XML (React DOM vs. React Native). Throw in a component lifecycle, and you're good to go. Sure, it's not jQuery simple but for a modern SPA it's about as good as it gets. It allows you to just deal with things in terms of composed functions which is wicked elegant, and since you're almost surely thinking of your page and application hierarchically it maps to reality nice and clean.
Redux makes managing global / central state reasonable, and in conjunction with the `connect()` function allows you to A) pull in needed global state and B) dispatch data to be centrally processed such that your component gets to not give a shit. It'll just update as-needed. It's dumb.
Strings for types sucks (it's better with Flow, or Typescript I assume) but it is what it is... the immutability can also lead to some subtle bugs if you fuckup and mutate something, but overall I'd rather write a React app with Redux than without at this point just for ease of reasoning about the system as a whole.
If you've never dealt with this type of architecture, it can be strange at first but it makes managing state / data flow much easier.
>> But the point would be to start with the basics and build up an understanding of why we need these libraries. And what problems they solve and what problems they don't solve.
This is exactly what the well-written official React docs do. It doesn't involve any CSS-in-JS, Redux, Thunking, Webpack, etc.
1) Start off with a basic app - build the Tic-Tac-Toe app through the official React docs
2) Build a simple React app with the official CRA (Create-React-App) tool
3) Build a more complex app
4) Keep building a more complex app, learn about routing, lifecycles, performance...
N) Look into Redux if you need it
---
Re. Redux:
The React docs have jumping off points throughout this process to understand why setState-based state management can get difficult in large applications (prop drilling) and the problems Redux solves. Look at this excellent doc on 'Lifting State Up' (https://reactjs.org/docs/lifting-state-up.html). This makes you go through the motions of setting up a component with setState, lifting state up, and experiencing prop drilling. Redux isn't even mentioned here.
Re. Thunking:
In the 'Basics' section of the Redux tutorial (https://redux.js.org/basics/actions), here's an excellent snippet: "Action creators can also be asynchronous and have side-effects. You can read about async actions in the advanced tutorial to learn how to handle AJAX responses and compose action creators into async control flow. Don't skip ahead to async actions until you've completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions."
Re. Reselect:
Again, in the Basics section, in "Usage with React" (https://redux.js.org/basics/usage-with-react):
"These are the basics of the React Redux API, but there are a few shortcuts and power options so we encourage you to check out its documentation in detail. In case you are worried about mapStateToProps creating new objects too often, you might want to learn about computing derived data with reselect."
None of these 'power options' and extra tools are talked about in depth in the Basics sections of any of these docs. They are mentioned as jumping off points and the reader is warned not to dive into them early without continuing with the tutorials/docs. This seems to be exactly what you're looking for...
Yeah, I guess I'm not giving the documentation enough credit here. The main issue I see is all the companies rewriting their applications in React. Because I don't think they see it as a complicated engineering decision with tradeoffs and potential issues. They see it as "we need x buzzword and y buzzword". I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this". Because it's very easy for developers, especially magpie developers or younger developers to think "oh yeah, of course I need this. I need my app to be S C A L E Able". The idea behind the tutorial would be giving precise problems that are solved by the tools, while also demonstrating what can be accomplished without them.
Also, is it just me or is the tic tac toe tutorial really not useful? Sure, it's a good isolated example, but it's a really contrived one as well. Something like an address book or a blog would be a lot more fitting with people's usecases.
>> I'd prefer that the documentation outright say "This is a BAD idea if you're just doing xyz" instead of "if you need, you can check out this".
That's a good point - I wonder if devs think enough about when not to use the tools they build. I was about to mention that the Redux docs do this but the only thing I could find was the 'Before Proceeding Further' section on the first page. I think my impression came from Dan/Mark's tweets and articles, like this one: "You Might Not Need Redux" [0]. But even that article talks about all the benefits of Redux first :)
>> Also, is it just me or is the tic tac toe tutorial really not useful?
I agree it's contrived. Building a game I think is a good way to get introduced to working with state in a slightly more complex and interesting way. React is at its heart all about rendering a state machine. It's up to you how to represent that state machine - either as primitive state, context provider, or redux. Personally I'm not a fan of address book examples but that's just because I've seen so many of them they don't hold my interest...
Writing docs is hard. To quote Dan from when he was writing the initial Redux docs:
> So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”
Both React and Redux introduce a lot of new concepts for someone coming from a typical jQuery / Backbone-type background. The larger the example apps you show, the more potential there is for them to get lost on what concepts are actually relevant (which is actually part of what Brad was saying in the original linked post for this discussion).
The docs for both React and Redux are open for PRs. If you feel that we need to have sections that better lay out the pros, cons, and reasons to use React and Redux, please submit a PR and we can figure out the best solution from there.
This makes me sad as I can’t help feeling that Redux being promoted (earlier on in React’s life certainly) by the community as the de-facto way to manage state has caused a huge amount of pain for newcomers.
This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that being introduced to the complexity of Redux completely ruins people’s first steps in React (the two are often seen as inextricably linked to newcomers).
Personally I feel the community should be pushing people much more towards lighter weight solutions such as component state and MobX for when the application grows.
I know Redux has theoretical advantages but in the real world I’ve always found it a large burden and would personally use MobX in preference every time (which isn’t to say MobX also doesn’t have its rough points, but it’s much more intuitive).
So our React site is fairly static, but as it grew we had more and more state to manage across components, and more of it trickling down; in some cases state would come from fairly high up in the structure, and have to be ingested pretty far down the component chain.
So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 layers down, because every time I'd point childContext to them, they'd point to the part in the docs where it says it's experimental tech and that it could be removed in the future. I'd point out that the React devs have a very sane code-breaking policy and we'd just cross that road when we'd get there. It's not like we're aggressively updating to the latest release anyway. Some other people would suggest using Redux, but would agree with me that we just didn't manage _that much_ state.
(We also have a React Native app, and as we manage more state in there, we did implement Redux, though it still bothers me as a tech.)
Anyway, fast forward to last month, where I read Abramov explain that Redux actually uses childContext!! So:
1) there's no way they'd just rip it out of React without warning,
2) if childContext works for you, don't worry about the complexity of Redux, just pass down state and a few state-modifying functions in childContext!
Old context will continue to exist through React 16.x, but will be removed in 17.0. Meanwhile, we've got a proof-of-concept PR open for React-Redux to switch it to use the new context API instead ( https://github.com/reactjs/react-redux/pull/898 ). Given the other changes related to React 16.3+, we're likely to put out a React-Redux 6.0 that includes the context usage changes, and make it 16.3+ only.
All that said: you really _should_ stop using the old context API, upgrade to React 16.3, and switch to the new context API instead. It solves the issues inherent to the old APIs design, and is the supported approach going forward.
I suppose the “early on in React’s life” part is relative. The era before Redux, though, was far worse. There were so many flux implementations with very different answers for even the most fundamental questions (like where to put data fetching and side effect code), and none of them developed a community large enough that these answers were sufficiently documented and discoverable.
Competition is good, obviously, and we certainly still have that, but I much prefer this era where there are a relatively small number of competitors in the space, each with (mostly) well-baked answers to common questions and mature and active communities.
I feel similar to both OP and you; especially when first learning React a year ago. I feel like the only real way to learn it is to get a job where you work with React full time, and after a few months you will finally get comfortable with it. (that's how I learned it) I was fortunate enough; when shutting down my startup a year ago and needing to land a new job, a team of coworkers I used to work with took me in without much of an interview, so I was hired into a React shop even with zero React experience. I can imagine the predicament when you have no React experience, and also can't get a React job to learn it.
I learned React before all these unnecessary addons and it was still borderline terrible. JSX and its school of thought is a horrible, horrible mistake and having to learn to use slightly-different names for everything (className vs class, etc) was infuriating.
Still, everything one needed for an SPA was there. With thoughtful design one didn't need any of those addons. Then, suddenly, Flux comes out and it seems like a few months later the whole scene says React+Flux is the only way to go. (I personally found Flux confusing as fuck, but I didn't give it more than 15 minutes) It amuses me to see some of these JavaScript proponents get so cocky over something that only lasts a couple of months.
FTR changing class to className and for to htmlFor is not JSX, but React specifically. If you configure JSX to use a different hyperscript framework (Mithril is the one I use), then you can keep the standard HTML attributes.
If the author sat down for an afternoon he could fix most of these struggles, in probably less time than was invested writing about them.
The thing about ES6, braces, promises, and anything else in programming is that you need a few core examples to wrap your head around and everything else is an application of that.
Every question is easy to answer once you know the answer, the trick is finding the answer. It's often harder to know what you don't know, than actually finding the answer.
I agree with this statement, but in this case the author lists concrete things he has difficulty with, like => and promises.
I am responding based on my experience doing some react/redux work coming from a non-JS background, but the author says he is a designer so maybe that's where the difficulty is coming from.
That's not to say there aren't hard parts, but those come farther down the line when you're trying to do something unconventional.
But I just want to say, as an alternate data point, my experience has been exactly the opposite. I love React. React is the first front-end technology I have ever managed to get to stick.
* ES6 is just a detail, I know. But for me, ES6 transforms Javascript from an idiosyncratic scripting language where I constantly have to look up the ordinary way to handle basic programming tasks into something resembling a modern high-level language. To me, ES6 turns Javascript into Ruby. I don't love programming in Ruby, but I can do it quickly and without the language getting in my way.
* The basic idea behind React, that your UI rendering code is always working with a snapshot of the current state, and 95% of your job is just to take that state and re-render it wholesale, eliminates a huge amount of the cognitive load I experience trying to do front-end stuff. I allows me to stop thinking in state machines, and just write straight-line code. If you've been primarily a backend person and have always sort of hated doing front-end stuff, check out React and see whether it's just the programming model that's been bugging you.
* Unlike the author, I've always been more of a programming person than an HTML/CSS person; I would kind of rather eat a bug than fiddle with CSS. One thing that makes React so nice for me is that you can just buy an HTML template and gradually turn it into JSX to "animate" it into a UI. Another thing is that it so nicely decomposes into components that there are a bunch of high-quality UI component libraries to draw from.
I have a lot of the same problems with React that everyone else does:
* "This" and the JS class model still feel like own-goals and I'm regularly tripping over them. But I'm never stumped by them; the bugs are always pretty obvious and easily fixed.
* Perf has been an issue, particularly memory consumption. But to me, this just suggests that I'm actually productive in React, that I'm getting to the point where I'm comfortable enough belting out code that I'm generating perf problems to go fix. (This has come up on relatively complicated UI projects, like the debugger interface we did at Starfighter, which was a monstrosity).
* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.
* I still have no idea what the right way to test things is.
I'm not rebutting the article at all! Different people, different issues. I just thought, if that perspective was valuable, mine might be too.
>>* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.
But what happens when you inevitably need to step outside the boundaries set by create-react-app? From that perspective, it simply delays the problem, rather than solving it.
I don't know, because haven't needed to step outside those boundaries. I'm sure it will be painful when that happens, but by that point, I'll have gotten so much done that I probably won't care too much.
I had a gulp build process I used before create-react-app; it was gross to get working, but then worked just fine. I could live without create-react-app, but why would I?
If you hit the point where you're considering ejecting, check out react-app-rewired. If you just need additional Webpack plugins, react-app-rewired can do that for you without the need to completely eject your app.
You can eject the app to exit CRA's umbrella. All of your configuration and code still works, you just also gain access to the project config and Webpack config that CRA formally dealt with for you.
A lot of the time, simply using react-app-rewired is sufficient in place of ejecting, especially if the only thing you need are some Webpack plugins.
I guess it depends on how you learn. I personally used CRA in my learning process and it helped me get up to speed in understanding React fundamentals (reconciliation, lifecycles, state management..) Then I started going down into the stack and understanding Webpack, etc..
For me personally it would be exasperating to learn all of the stuff that CRA bootstraps before actually getting to learn React.
> But what happens when you inevitably need to step outside the boundaries set by create-react-app?
Been working on a real-world c-r-a based project for 8 months and this is yet to happen. And the upgrade process has been a dream (update 1 dependency), no breakages so far.
In fact I now regret my other attempts to go off the rails (adding Sass), it wasn't worth it.
Some unsolicited advice from someone who has also been down a similar path.
I normally suggest eschewing the javascript class model in favor of using stateless functional components.[0] I've found them simpler to understand and it cuts down on unnecessary typing. I almost never use 'this' in javascript, and instead have favored an OLOO[1] or pure functional style as it fits into a simpler mental model for how things are working.
I normally only test the actions that modify state in my javascript applications. I care that I'm correctly changing the state of my application, not what that state renders. (This is similar to rails apps not typically testing html output) I normally use mocha[2] for testing and if something goes wrong I can open up a normal chrome js debugger using the --inspect-brk flag when running via the cli.
You will eventually find yourself needing to support multiple routes in your react applications. Most people would recommend the "react-router" library, but I've found a lot more success with "redux-little-router"[3]
And I 100% disagree. If you're new to React I strongly recommend sticking with classes and embracing React's 'component' model which is one of its strengths and which Redux + trying to use only stateless functional components throws out with the bathwater.
>I normally suggest eschewing the javascript class model in favor of using stateless functional components.
So I do this whenever possible, but the way this advice is worded (both here and often in the wild) makes it sound like you can just use them everywhere.
Most UIs have state. I can't imagine a UI that doesn't. Every third component or so I write I end up using classes for, so I've got a mix of classes and functional components throughout the codebase. Do you _never_ use classes? If so, what do you do instead? Otherwise if you're like me, you get to use functional components occasionally which is nice, but are nowhere near being able to get rid of the class syntax.
I only use classes when I need to use a ref within a component (which is quite rare). I use redux for all my state management instead of storing state within the component itself. Everything else is a stateless functional component. A typical component would look like
import React from "react";
import { connect } from "react-redux";
function _HelloWorld({name}) {
return <div className="intro">{name}</div>
}
function mapState(state, ownProps) {
return {
name: state.name
}
}
function mapDispatch(dispatch, ownProps) {
return {}
}
export const HelloWorld = connect(mapState, mapDispatch)(_HelloWorld)
I realize this is just a snippet and probably written off the top of your head (rather than reflecting real code), but a couple quick suggestions for improvement there:
- Only add the `ownProps` argument to `mapState` or `mapDispatch` if you actually need it, because `connect()` will now call those functions more often (whenever the incoming props have changed). If you're not actually _using_ values from `ownProps` in there, don't add those arguments.
- The `mapDispatch` function isn't doing anything at all in that example, and can be omitted completely
- I personally recommend using the "object shorthand" form of `mapDispatch` instead. To me, there's never actually a good reason to write a separate `mapDispatch` function. Just write action creators, and pass them in an object to `connect`, like this:
Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle.
For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out!
Same here. Learning React for me was pretty simple. I think many get confused as to what React is and what it isn't. Like many view or template libraries, a React "app" is really just a function that takes properties and outputs markup. In React's case, there's a little more behind-the-scenes magic as to when changes propagate to the DOM, but the concept is still very similar. React isn't MVC/MVVM/MV*/etc, it just manages the view layer. With React, you also get the ability to render server-side and target other platforms such as iOS, Android, etc.
Redux on the other hand was a little more confusing for me to learn (the concept makes complete sense, it's the implementation and debugging that gets confusing). The great thing about Redux is that you don't have to use it or learn it. The React ecosystem is pretty well decoupled so you can choose how you want to manage state and async tasks. That is it's biggest selling point for me personally.
My experience with front-end frameworks started with Backbone + a ton of jQuery to AngularJS to React (with many different state management libraries). I found that Backbone didn't really provide much on top of jQuery + lodash/underscore, but I liked that it didn't make too many decisions for you. Angular (v1) on the other hand, forces you into some unconventional patterns (ie: the whole service vs factory fiasco and it's own dependency management system). It's fine if you aren't using a separate dependency management library (or ESM), but if you are, you have to declare dependencies twice. Angular 2/4/5/whatever-arbitrary-number-they-are-on-now has been way more confusing for me to learn as they make you learn their own templating language for things like loops, control flow, etc and still have some weird patterns around dependency injection. JSX is a lot simpler if you know basic JS. React seems to have the least amount of boilerplate code as well especially if you make use of functional components.
I still have no idea what the right way to test things is
At my company, we use cucumberjs (https://github.com/cucumber/cucumber-js) to write scenarios for basic front-end testing. I wouldn't go overboard and start writing test to measure padding or font sizes, but you can easily see isolated scenarios and write automated tests to simply verify that a react component actually put the right element in the dom or to check conditional class names.
We also unit test many of our Redux reducers which is pretty simple with any unit testing library. Just create an initial state and expected state, call the action creator, and deep compare the new state with the expected state.
I think it is worth learning Elm first because it many ways it is much simpler. No JS "this" issues to worry about. No props vs. state. It is very opinionated. But it is also virtual dom and "component based" so the paradigm is instilled in the brain to go across and learn React.
Disclosure: I learned some Haskell before Elm so I may be "immunized" against some of the struggle!
For building understanding and mental models, I think it can be bad to jump into things that are too much of a struggle.
However the best of both worlds is some kind of tutorial that explains it really well. Like the recent "explaining functional programming to my 6 year old" article. Then you can dive straight in, but get off to a solid start.
Svelte - https://svelte.technology/ has components written in HTML. It's compiled to vanilla javascript, which results with components that are faster, use less memory, & have a smaller payload.
Also, Svelte is easier to work with. A simpler API, Computed Properties, events. The Svelte Store is also nice. I'm forced to use React in a project, but I prefer to use the Svelte Store opposed to Redux or MobX.
For me, the process of learning React has been terribly frustrating. The ecosystem moves too fast, and the various training materials out there become outdated very quickly. I was going through one of them and got stuck several times, and after spending several hours I found out that the function call covered in the course had been deprecated.
The takeaway I got is that it seems like the React stack has worse or non-existent separation of concerns and thus it'll affect how your frontend engineers work, possibly to their detriment if they're not proficient in javascript.
re: #5: At my previous job we wrote our own UI toolkit with React and css-modules. We had many dev-only views that we used to inspect and test our components. It worked great because it let you visualize all the states a component could have for a wide range of inputs, so you knew they were all being handled well. For example: If you get a long input prop do any of your styles break from visibility overflowing? If a nullable value is missing, are you styling it appropriately while showing a placeholder? Unfortunately it wasn't open source, but it's being done.
This is pretty cool. But I've seen it done at a handful of companies. Where they have component libraries written in house. All those companies never open sourced their work - and it seems to me that it's a lot of reinventing the wheel
I guess this is part of the whole divergence of the JS community.
This is one of the questions I ask at every interview I do now when looking for a new gig:
"Do you prefer one JS framework does it all like AngularJS, or do you like to mix and match your JS libraries like taking ReactJS and combining it with say AmpersandJS, BackboneJS, etc?"
This is where we are. One group wants to use ReactJS and add complexity as they need it. Others just want a complete framework (however complex, and let's be honest, Angular is pretty complex!) out of the box. I've always been happy with full stack frameworks out of the box for several reasons, but it's what I prefer.
I'd be interested to know where all of this ends up in the next 18 months though.
I think this is the reason so many are picking up Vue rather than React or Angular these days. Vue offers the component approach and is generally fun to learn IMHO.
I have done both Vue and React projects. I like React philosophically. But my coworkers, who were keen to learn react, struggled conceptually and I ended up doing a lot of the React work. Then on another project we trialed Vue which worked out far simpler for people to learn and I also find I'm far quicker developing things using Vue. So while I'd tend to recommend Vue, I'd encourage people to trial both on something not too trivial before settling on either.
I've been doing React Native development in my spare time, and I've found that React is...finicky. `class` this and `extend` that, and if you get it wrong, the whole thing screeches to a halt. There are a few other comments noting that it's mostly difficulties learning ES6 and I would actually agree - that doesn't mean React itself is any less difficult to learn, due to the fact that the entire ecosystem depends on all of these ES6 features.
I was discussing this with another developer who had the same sort of impression - it seems like it should be simple, conceptually, but there are a myriad of details to keep track of to keep the build system happy, to keep the components happy, to keep JSX happy. Compared to learning Vue, the whole process is much more difficult.
I've also struggled to learn React, but for me it's because I learned ClojureScript/Reagent/re-frame first. I get demotivated because I vastly prefer those tools, but unfortunately there are many more job opportunities for JS/React than CLJS.
My approach to React was similar to Brad's, as I am far more proficient with HTML and CSS than JavaScript. I'd done plenty of wacky stuff in jQuery, and that tutorial demonstrated how React can iron out some of the problems that spaghetti jQuery can create.
I'll also add that part of the problem with wading into React is that, if you're a certain kind of frontend designer, you remember the browser wars, and you would often wait until tech was mature before you went out and used it in production. But React was adopted quickly and has changed quickly. React Native is even worse in that regard. So even if you learn how to do something a certain way, that knowledge could be obsolete in a year, or less.
I've been writing Java for 20 years and never for a moment had the least doubt about the value of 'this'. ES6 has been slowly morphing into Java yet it hasn't solved this basic issue very well.
At this point, the JS ecosystem with React is a bit too complicated for a hobbyist to learn quickly. I have friends spending months with just React, not including other libraries.
But React is a tool for building complicated UI's, and overwhelmingly complicated UI's are requirements for startups, corporations and organizations, not personal sites or small toys. So like many other technologies, this one is perhaps best learned on the job, and it doesn't need to be optimized for the hobbyist.
That being said, losing the hobbyist comes with serious costs to community and innovation, a fine balance needs to be found.
Agreed. I am very familiar with most front-end stacks. I typically choose React for my projects, and I really love it. But when a beginner asks me "What is the best framework for me, having little knowledge of front-end dev/ecosystem?", I almost always just recommend Vue.js. I personally don't mind the setup of React, even for small projects, but I wouldn't wish that upon someone jumping into front-end dev for the first time.
I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go.
That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very well.
As of now, I have still yet to see a JS framework that made any sense to me. They're all really weird to me and solving problems I've never had with UI development, or regressing previous best practices in ways I don't think make any sense.
I'd much rather just use template rendering than this stuff most of the time. At least with that, you're just using Real JavaScript (TM) and you don't have to learn some new special HTML attribute based language.
Honestly, something like React/Vue has got to be as close as it gets to "The Final Paradigm". At this point, it's been a long time since I've seen a new paradigm that does anything vastly different or more productive and simple than JSX + React/Vue lifecycle & state hooks. Most of the new UI libs that come out (Glimmer, Marko, etc) seem to be heavily influenced by React and don't offer a giant leap in how UI is done.
I think there's plenty of more opportunities in state management, CSS management, application structure, tooling, and making those more simple, but generally I think the view layer is more or less solved.
It's funny to think retrospectively that something like Backbone.js absolutely did not solve view state management at all and people adopted it because it somehow looked like Rails with big models, Angular.js misunderstood the issue completely with factories everywhere instead of a single dataflow.
The new paradigm would be the browser handling all that and there is no need for frameworks anymore. We are not there yet given how poor web component support is : https://caniuse.com/#search=web%20component
I think you nailed it (though I think Jeremy Ashkenas and Mike Bostock and that NYT group are brilliant... especially working in the media space at a company that doesn't encourage that kind of work to put it mildly).
I've had my whimsical entries into experimenting with Web Components, but they just haven't felt like they're quite there—ignoring the lack of support. They're workable, but I think design patterns surrounding current paradigms might need more readily addressed. As they are, you'd probably want a framework on top of Web Components to improve the semantics and just make working component state in generally less verbose.
I have a hastily-written example here playing with them:
I don't think so, I'm thinking it's all about to change . why? WASM.
We now see languages targeting the browser, and the beginnings of front end frameworks being developed in traditionally backend languages. I think this is going to create quite a different landscape for the web world in the next 5 years. Different languages bring different approaches to problems.
No reason why React couldn't be implemented in WASM. I'm less bullish than you are about WASM, though, since DOM interaction is going to be the bottleneck no matter which way you slice it.
I haven't found a JavaScript framework that truly makes things easy. I've been a developer for a long time, going back even before the web itself, and a lot of the older technology was pretty easy in comparison to what we have today for web development.
My impression of React is actually quite positive; it solves a real problem in a highly performant way and with a relatively good model. But it is still pretty low-level to me; even if you add in a dozen or so other libraries.
My needs are fairly different from Facebook or most startups -- I don't work on a single highly optimized application -- I build a new application every few months (and maintain all of the previous ones). The current set of JS frameworks don't do a lot to help me.
> If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very well.
This makes me think of an interesting/bothersome phenomenon I've seen a lot in web development (it seems to be more present here than in other domains—but I won't pretend to have any profound objectivity on the subject). People speak confidently about rationales for architectural decisions—and at first it sounds coherent and persuasive (especially paired with their confidence), but if you start trying to test it, considering specific cases, or more generally just drilling into the specific meanings of the very abstract statements—then you are likely to discover that the supposed rationale is really a justification.
I'm guessing this comes about because decisions about technology often have to be made with time constraints, and the time required to really investigate the set of viable alternatives exceeds what's available. So you're left with a partially completed search process, where the engineer has told himself a story about why choice X was the best, based on promising looking aspects of the search so far completed.
At this point, you're sort of committed to the decision you made, so you have to continue justifying it to yourself and others; and since there isn't necessarily a valid justification, the one you employ has to succeed in part through its obfuscation and your rhetoric.
> web application / UI frameworks that are going to be the The Final Paradigm come
Are there any that would claim that? As far as the popular ones that have been there (which is really just JQuery and Angular, but could also encompass thins like Underscore, Knockout, etc.) go, I think most of them presented themselves as band-aids for limits in Javascript/DOM API's. I think React is that first one that gained widespread adoption that actually promoted a paradigm (view is a function of state).
That is not to say it's The Final Paradigm, but I think an important reason for both Angular and JQuery to lose adoption is because the wounds they band-aided over were cured.
> As of now, I have still yet to see a JS framework that made any sense to me.
The basic issue with the DOM is that it makes state management a pain in the arse.
So you have written a DOM widget and you want to incorporate it in a bigger widget, so you have to have some kind of "composite" API with a widget life-cycle that pumps data and dumps custom events from/to somewhere. It's not that hard to code, but by the time you are finished coding a library that handles all that you have created you own front-end framework basically.
Web Components help a bit by it doesn't seem that Google, Mozilla or Microsoft and co are doing a very good job at promoting them, pushing them in their browsers or even education people about them. It looks like it is one of that spec browser vendors don't like for whatever reason :
Vue.js actually retains most of the philosophy of Web Components like Polymer so I went with that instead of React,Angular and co. Front-end development is all about state management.
I'd like to know how implementing a template parser in JavaScript is more "Real JavaScript (TM)" than an actual function call (i.e., `React.createElement`).
Angular/React/Vue is nothing more than template rendering, with built in data binding. It is a major leap in the way you write web UI, enabling true separation of view and business logic.
(ok, slight lie, there's tons of other junk inside those frameworks also, but just stay away from everything except the data binding and you'll be much happier.)
217 comments
[ 3.6 ms ] story [ 258 ms ] threadAlso I'm curious what podcasts you were listening to? Has anyone picked up a new language from listening to a podcast. I can't imagine getting much out of it without the visuals to go with it.
create-react-app is awesome and huge time saver but as soon as you have to step outside of that realm there are so many dependencies and other tools to get the sausage made that it's daunting for new-comers.
It's not at all fair to compare JS and Go BUT that is the one part of Go I really, really love- `go fmt` is built in and most of the tooling Just Works™ with minimal config (e.g. gometalinter). I find myself stuck when figuring out where the next piece of the JS puzzle should go in my local dev at times and how to make some other things production ready. But we're in a much better place now than we have been!
To be fair, this reads to me more as a midstream reflection on the learning curve, not supplying any kind of solution for any of them.
This is why a lot of front end folks should look at an alternative like intercooler:
http://intercoolerjs.org
It is far less violent to deal with, with a much lower barrier to entry and satisfies most needs of most web apps.
Perhaps some UIs are so complex and dynamic that they're easier to build and maintain using React. I'm not saying other people shouldn't use React, but I'm fairly certain it wouldn't give me enough payback to justify the investment it requires.
Aside from that, it and a handful of other technologies (webpack, maybe redux) seem to be coming out ahead as industry standard for SPAs. So yes, learn it “for your resume”, or as I like to put it, “staying employable”.
Edit: this is assuming you already have a SPA based CRUD app. If you are rendering server side then by all means keep doing that.
I realize you're just trying to be dismissive, but in point of fact, my CRUD applications are far more complex than basic todo applications.
I think that's a fair point. And I think others have remarked that it illustrates Conway's Law.[1] For a front end like Facebook's, that has numerous moving parts, developed by different teams scattered all over the world, and those parts have to fit together and work together in combinations that may not even be foreseeable, then a framework like React may be the only possible way it could be successful.
[1] https://en.wikipedia.org/wiki/Conway%27s_law
It's frontend technology that is robust enough to deliver Facebook. If you haven't worked on or aren't working on a complex UI with a team of developers, you might not appreciate how incredibly solid React is. This isn't something that can be explained well through anecdotes, but this comment is getting at it:
> Its top down `(props) => rendered view` paradigm is a breath of fresh air if you've ever spent a significant amount of time in an Angular 1.x application with a complicated web of watchers and scope sharing all over the place.
The complicated web issue isn't peculiar to Angular. Many UI frameworks are modeled in such a way that they become a rats' nest of objects, events, etc. all firing back and forth. Using React with good practices enable an overall structure that mitigates that tremendously.
What is a problem though, is that there is no consensus in the team about how the code should be structured. So everyone creates their own mess.
Oh state management? There is something called observer pattern for that.
React gets you a consistent UI paradigm (state->ui) that scales well as your app gets more complex or as more members are added to your team.
It fits like a glove. And while it's not all roses, there are fewer friction points it seems than in JavaScript (but then I think JavaScript programmers don't have it easy anyway). Plus, because of the nature of ClojureScript, most articles I read about optimizing React performance do not apply to me, because all the hard work has already been done for me (for example, immutable data structures mean that you can efficiently prevent re-rendering if data hasn't changed).
Anyway, to sum this up with an example that I'm basing my opinion on: PartsBox (https://partsbox.io/) is something I wrote, using React.
For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: https://github.com/Day8/re-frame
1. Assuming you have leiningen installed, run `lein new figwheel hello-world -- --reagent` and follow the instructions in the output
2. Follow along with https://reagent-project.github.io/
3. Enjoy a nice, refreshing beverage.
I do not recommend Om for starting.
And then, to top it all off, you can't just use React, you need to pair it with a set of other libraries, each with their own set of ridiculous jargon and paradigms.
I honestly think a bunch of very talented Facebook devs got bored and decided to make something complex just so they could keep themselves entertained. And then other developers followed suit because it has cool words that make you sound important and inflate your ego, even though it's doing the same shit the web has been doing for 30 years.
const HelloPerson = ({ person }) => <div>Hello, {person}</div>;
ReactDOM.render(<HelloPerson person="ChrisCo" />, document.getElementById("root"));
That's elegant as fuck.
I've played around with an idea for a tutorial on modern web development that starts with just basic JS DOM fiddling, then introduces various features and techniques as they're needed. So you'd start with just using old school document selectors. But then, as all the getElementByClassName calls become annoying, maybe you'd introduce transpilation, so that you can querySelector with a map/filter. Then, as the updating starts to get hairy, you could introduce a library like React. As state becomes an issue, Redux. But the point would be to start with the basics and build up an understanding of why we need these libraries. And what problems they solve and what problems they don't solve. But of course, the moment anybody writes this tutorial, half of it will become outdated. Ah well.
Even Redux's author tells people Redux is overused. A pretty big percentage of the value of the flux pattern is just in having an event pubsub system, so if your application is so complicated that you really feel like you need to structure it, you can just use EventEmitter.
I frankly don't understand the popularity of React Router. The core thing React Router accomplishes can be done in ~50 lines of code including the switch statement for "routes". If you like and grok React Router, use it. But I don't think it's a good idea to push through your resistance to it.
Of course, I say just buck-up and learn the damn thing, it isn't that complex... earn the "Engineer" in your job title!
Maybe I'm just an out-of-touch neckbeard these days?
So yeah, it works good when you get it working, so yeah, the best thing to do is to just buck up and learn if it you need it. But boy does it suck getting there.
All of that said, I don't understand where this view comes from that Redux is extremely confusing. It can indeed sprawl a little. Say, if you keep you containers, reducers, and actions in their own directory trees. The overall architecture didn't take me very long to grasp and start to leverage.
Plenty of folks find their home in Flux or MobX instead, but I'd have to guess that a lot of the confusion is actually confusion about state containers and their uses.
If the router was just "Buck up, learn it, and you're golden" I suspect we wouldn't hear too much hollering about it. Unfortunately, the hassle of using it is so close to clockwork I feel like I should just schedule a week every six months or so for maintenance.
I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems. I wouldn't mind that much except that wrapping a React component around a fragment of HTML is not a problem so difficult that I'd endure compat problems in a dep to solve it.
With the router, it was never a matter of us just deciding to upgrade for the sake of upgrading but rather ending up being painted in a corner with peer dependencies requiring upgrade. Additionally, because we were a micro service / many SPA outfit, we ended up with a dozen or more applications at varying levels of libraries so you had to deal with 2.x, 3.x, and 4.x or just upgrade.
For those of you reading along thinking "This sounds like a dysfunctional environment!" You're right! Imagine having five heads of department, albeit two interim, in a year.
> I had the same problem with react-bootstrap, which I used for about a year and ran into regular upgrade compat problems.
I'm in the middle of building out an internal component library based on `react-bootstrap`, so that's fun to hear...
Have your issues mostly been upgrades of the library? Or of Bootstrap versions? We internally decided we're just sticking with Bootstrap 3 for the foreseeable future with the hope that it will mean we don't have many issues to deal with.
It's possible react-router has settled down too, but the experience I had of "I can't believe I ever wasted time trying to figure out react-router" after implementing a "router" myself was so powerful that I'm pretty averse to finding out.
That layout is the biggest reason it took me so long to understand it when my team brought it in.
It goes a bit against the spirit of Redux, but the tutorials really should pair up action and reducer in the same directory, then later explain why the other way is also useful.
We currently do this:
It ended up way, way easier to understand and get people in on it, because in the vast majority of cases we don't need multiple reducers listening to the same action.For the size of the tutorials, it's probably simpler to use a "folder-by-type" structure. But yes, for real apps, I myself have settled on a "folder-by-feature" structure. Note that either approach is completely orthogonal to whether you have multiple reducers listening to the same action.
The tutorial is already trying to explain a lot of concepts that are new to most people, so we try to keep it focused on the meaningful concepts. Throwing in side discussions on folder structures would probably add more confusion at that point in the learning curve.
> so we try to keep it focused on the meaningful concepts.
For me, scattering a single feature across multiple directories makes it far harder to understand what relates to what. It's _less_ meaningful to group by type than by feature, which makes it harder to learn than it should be.
I'm not saying the docs should go into asides about the alternative structures all over, but rather the people promoting Redux should definitely consider whether or not their examples smell more of spaghetti code than they need to be.
If you take the recommended path, i.e add redux iff you need it, you've already settled away from folder-by-type. It's natural to organise by feature since you're generally doing it anyway by that point.
Instead of a rework, it might be easier to add a small page on folder structure.
Noticed you on Reactiflux too, hi!
You want the things in your app that look like links to have some interesting behaviour. They should look like links, they should act like links when right-clicked.... but when left-clicked, they should not actually load the new page. Instead, they should update the History and also trigger the router to reconsider the routing. That's why ReactRouter includes Links and Redirects.
I suspect there's at least one other feature-of-some-utility in it that I can't think of right now. Hmn.
There's also some weird logic around multi-routing, which I suspect is a bug rather than a feature, but maybe there's a sweet use-case. And there's also some weird stuff about not propagating children, which seems like a bug not a feature, but the workaround is easy, and again maybe there's actually a good reason, I dunno.
Anyway, as with what you talked about, this isn't rocket science, you could do it yourself with some work. But if someone follows your advice and thinks that's the end of it, they'll eventually feel some minor pain points.
That said, I honestly can't be bothered to actually properly learn React Router. I think that some company, ideally one specializing in react training, should write better documentation for it.
He teaches a good chunk of the react nanodegree course on Udacity and has a lot of good blogs on react.
You also have a few (single-digit) lines of code to wire up the history API so that the back button works.
You have a tiny helper function that uses the history API to directly navigate to a URL inside your application.
You have a tiny Component that renders an <a>...</a> whose onClick calls that helper function.
I'm sure React Router does a lot more than this. I mean, it'd have to, right? It's so complicated. But I don't know what those things are, because until I'm forced to, I'm not going to bother with it.
Similarly: I appreciate flux and think Redux is a reasonable implementation of it, but at this point, after doing a couple applications with it, I'm going to get as far as I can with a simple EventEmitter and hierarchical state before I bring it into a project. For straightforward applications --- really, a pretty big chunk of the apps I see are fundamentally straightforward --- I don't think it's a win.
When React was originally released it was sold only as a view layer that you plug into your application stack. Since no official way of approaching the rest of the stack emerged from Facebook, when Flux was announced it seems that it was taken as the rest of the stack by many.
I'd also just look at the React Router codebase. The components are pretty well written and somewhat easy to understand: https://github.com/ReactTraining/react-router/blob/master/pa...
I believe this is the post [0] in question.
[0]: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Not to mention the times where the codebase predates you. My first experience with React was on a codebase that was pretty horribly managed. Basically a combination of magpie developers and a total lack of understanding of React patterns. When the developers are finding and trying to integrate the next new shiny lib every other week, it becomes a nightmare for any new developers.
First time I used react I hated it, because everything was done through flux, want to add a field to a form. Now you need to update 4 different files and create 8 methods. Not to mention interacting with non-react components in a react way can be super painful.
It was insane. Second time I dropped all of the libraries. Only used react, and any time I needed to use a non-react component I wrapped it myself, and many times did very unreacty things like use methods to do a lot of interaction.
And I loved it. Everything is so much easier. I can focus on solving the user's problems, and not my react problem.
The apps weren't huge, but they weren't small either. 3 months of work for 3 devs full time.
It is a total nightmare and a horrible use of redux. That is like binding every variable and function to the window object because you have no concept of scope.
This is a pretty common theme for me when considering any react-* library, and I think it says a lot about how nicely React lets you abstract away behavior.
As for Redux, I feel like the payoff has been worth it, especially when adding in the benefits of tooling and middleware. When I learned React for the second time, I did it with Redux out of the gate, and while it did take a while to ramp up, the upside was I was able to see immediately where bugs were occurring (React + Redux DevTools) and didn't have to grok the component lifecycle before getting some data on the page.
For some cases you can just do a singleton on your shared data component. So for handling a multi screen form it just looks like export const MultiFormState = new MultiFormData();
Then import {MultiFormState} of course... Very useful. Between that and EventEmitter as you noted you can avoid a lot of extra code in many applications and get your components working well without the bloat and mental overhead.
I have a million LOC windows forms system that going to be ported to the web. I've reviewed React, Angular, Vue, etc. As a beginner, Vue seems the best to me, however, all of the experienced web developers I talk to recommend React. After reviewing the code and walking through tutorials it just seems like overkill and overly complex but I suppose I'm missing something. It's concerning because I need to have our team port a huge code base and am not sold on React but that's what we're starting with. The developers I talk to say Angular is too complicated and React has good component based features. Nobody has Vue experience. My gut tells me Vue would be better but if I can't find guys who actually use that and have React experience instead then it seems that's the direction to head.
[1]: https://mithril.js.org/
In the react realm, every problem is solved by throwing another layer of complexity/abstraction/whatever you call it
[1] Adapted from https://www.goodreads.com/quotes/175803-in-the-pursuit-of-kn...
Why do not use a more simple approach, say jQuery?
Once in a blue moon, I want to add a screenshot or other image to a post. Such images are of various sizes, mostly larger than the (max)width of the content. I use CSS to scale them down to fit with the text, but sometimes images displayed like that are too tiny to be legible. For a long time I handled this case by wrapping <img> with <a>, basically like this:
It works, and I like it, but it has a couple of drawbacks, most important being that it's kind of intrusive - by clicking it, you change the current url, and when you get back, even if your browser scrolls the page correctly, you need to find the place where you stopped reading.At some point, I gave up and included a bit of JavaScript, which enlarges the image while you stay on the same page. I used some kind of fancybox derivative - a jQuery plugin.
Now tell me that I should've used React.
For anyone else covering the same dilemma and doesn't care about transitions:
https://codepen.io/gschier/pen/HCoqh
Or, reduced further:
CSS
HTML As is, CSS is ~321 bytes(See CodePen link for code credit. Pretty clever little item, if you don't have to parse the pure markup. Even then it's not overly intrusive.)
Source: I'm currently building out my own Javascript-light blog/cv site, even though I generally like working with React. It's just not needed for everything. I'll likely extend on this at least a bit for some nicer effect with some current Javascript— barring older browsers from the lightbox effect but still able to read the thing in lynx and if need-be.
It shouldn't affect screen readers or Lynx users too much.
I also highly recommend Spectre CSS! I've been toying with it, and it seems like great work. I suggest checking out the "experimental" features.
https://picturepan2.github.io/spectre/index.html
I have had junior engineers read it in the past to get up-to-speed and it does a great job of teaching all of those technologies together in a way that makes sense and is easy to understand.
What's your take on things you miss from Redux now that you've switched over to Mobx?
mobx-state-tree is what you are looking for. You can model it similar to your Redux setup. It is immutable. It also has the snapshot stuff Redux has.
Redux makes managing global / central state reasonable, and in conjunction with the `connect()` function allows you to A) pull in needed global state and B) dispatch data to be centrally processed such that your component gets to not give a shit. It'll just update as-needed. It's dumb.
Strings for types sucks (it's better with Flow, or Typescript I assume) but it is what it is... the immutability can also lead to some subtle bugs if you fuckup and mutate something, but overall I'd rather write a React app with Redux than without at this point just for ease of reasoning about the system as a whole.
If you've never dealt with this type of architecture, it can be strange at first but it makes managing state / data flow much easier.
[0] - https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
Nit: It maps it to a virtual DOM, not XML.
That it transpiles down to something else is just an implementation detail to the developer. For all I care it could be jQuery statements :)
This is exactly what the well-written official React docs do. It doesn't involve any CSS-in-JS, Redux, Thunking, Webpack, etc.
1) Start off with a basic app - build the Tic-Tac-Toe app through the official React docs
2) Build a simple React app with the official CRA (Create-React-App) tool
3) Build a more complex app
4) Keep building a more complex app, learn about routing, lifecycles, performance...
N) Look into Redux if you need it
---
Re. Redux:
The React docs have jumping off points throughout this process to understand why setState-based state management can get difficult in large applications (prop drilling) and the problems Redux solves. Look at this excellent doc on 'Lifting State Up' (https://reactjs.org/docs/lifting-state-up.html). This makes you go through the motions of setting up a component with setState, lifting state up, and experiencing prop drilling. Redux isn't even mentioned here.
Re. Thunking:
In the 'Basics' section of the Redux tutorial (https://redux.js.org/basics/actions), here's an excellent snippet: "Action creators can also be asynchronous and have side-effects. You can read about async actions in the advanced tutorial to learn how to handle AJAX responses and compose action creators into async control flow. Don't skip ahead to async actions until you've completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions."
Re. Reselect:
Again, in the Basics section, in "Usage with React" (https://redux.js.org/basics/usage-with-react): "These are the basics of the React Redux API, but there are a few shortcuts and power options so we encourage you to check out its documentation in detail. In case you are worried about mapStateToProps creating new objects too often, you might want to learn about computing derived data with reselect."
None of these 'power options' and extra tools are talked about in depth in the Basics sections of any of these docs. They are mentioned as jumping off points and the reader is warned not to dive into them early without continuing with the tutorials/docs. This seems to be exactly what you're looking for...
Also, is it just me or is the tic tac toe tutorial really not useful? Sure, it's a good isolated example, but it's a really contrived one as well. Something like an address book or a blog would be a lot more fitting with people's usecases.
That's a good point - I wonder if devs think enough about when not to use the tools they build. I was about to mention that the Redux docs do this but the only thing I could find was the 'Before Proceeding Further' section on the first page. I think my impression came from Dan/Mark's tweets and articles, like this one: "You Might Not Need Redux" [0]. But even that article talks about all the benefits of Redux first :)
>> Also, is it just me or is the tic tac toe tutorial really not useful?
I agree it's contrived. Building a game I think is a good way to get introduced to working with state in a slightly more complex and interesting way. React is at its heart all about rendering a state machine. It's up to you how to represent that state machine - either as primitive state, context provider, or redux. Personally I'm not a fan of address book examples but that's just because I've seen so many of them they don't hold my interest...
[0]: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
> So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”
Both React and Redux introduce a lot of new concepts for someone coming from a typical jQuery / Backbone-type background. The larger the example apps you show, the more potential there is for them to get lost on what concepts are actually relevant (which is actually part of what Brad was saying in the original linked post for this discussion).
The docs for both React and Redux are open for PRs. If you feel that we need to have sections that better lay out the pros, cons, and reasons to use React and Redux, please submit a PR and we can figure out the best solution from there.
This isn’t the fault of the Redux authors - it does what it does well, and they’ve always said it’s not intended to be used for everything - but I honestly feel (and have anecdotally observed a few times) that being introduced to the complexity of Redux completely ruins people’s first steps in React (the two are often seen as inextricably linked to newcomers).
Personally I feel the community should be pushing people much more towards lighter weight solutions such as component state and MobX for when the application grows.
I know Redux has theoretical advantages but in the real world I’ve always found it a large burden and would personally use MobX in preference every time (which isn’t to say MobX also doesn’t have its rough points, but it’s much more intuitive).
So as I read the React docs, I discovered childContext, and I started using it. Some of my coworkers would stick to passing props along 2 or 3 or 4 layers down, because every time I'd point childContext to them, they'd point to the part in the docs where it says it's experimental tech and that it could be removed in the future. I'd point out that the React devs have a very sane code-breaking policy and we'd just cross that road when we'd get there. It's not like we're aggressively updating to the latest release anyway. Some other people would suggest using Redux, but would agree with me that we just didn't manage _that much_ state.
(We also have a React Native app, and as we manage more state in there, we did implement Redux, though it still bothers me as a tech.)
Anyway, fast forward to last month, where I read Abramov explain that Redux actually uses childContext!! So:
1) there's no way they'd just rip it out of React without warning,
2) if childContext works for you, don't worry about the complexity of Redux, just pass down state and a few state-modifying functions in childContext!
Old context will continue to exist through React 16.x, but will be removed in 17.0. Meanwhile, we've got a proof-of-concept PR open for React-Redux to switch it to use the new context API instead ( https://github.com/reactjs/react-redux/pull/898 ). Given the other changes related to React 16.3+, we're likely to put out a React-Redux 6.0 that includes the context usage changes, and make it 16.3+ only.
All that said: you really _should_ stop using the old context API, upgrade to React 16.3, and switch to the new context API instead. It solves the issues inherent to the old APIs design, and is the supported approach going forward.
Competition is good, obviously, and we certainly still have that, but I much prefer this era where there are a relatively small number of competitors in the space, each with (mostly) well-baked answers to common questions and mature and active communities.
Still, everything one needed for an SPA was there. With thoughtful design one didn't need any of those addons. Then, suddenly, Flux comes out and it seems like a few months later the whole scene says React+Flux is the only way to go. (I personally found Flux confusing as fuck, but I didn't give it more than 15 minutes) It amuses me to see some of these JavaScript proponents get so cocky over something that only lasts a couple of months.
The thing about ES6, braces, promises, and anything else in programming is that you need a few core examples to wrap your head around and everything else is an application of that.
Beautiful website btw.
I am responding based on my experience doing some react/redux work coming from a non-JS background, but the author says he is a designer so maybe that's where the difficulty is coming from.
That's not to say there aren't hard parts, but those come farther down the line when you're trying to do something unconventional.
But I just want to say, as an alternate data point, my experience has been exactly the opposite. I love React. React is the first front-end technology I have ever managed to get to stick.
* ES6 is just a detail, I know. But for me, ES6 transforms Javascript from an idiosyncratic scripting language where I constantly have to look up the ordinary way to handle basic programming tasks into something resembling a modern high-level language. To me, ES6 turns Javascript into Ruby. I don't love programming in Ruby, but I can do it quickly and without the language getting in my way.
* The basic idea behind React, that your UI rendering code is always working with a snapshot of the current state, and 95% of your job is just to take that state and re-render it wholesale, eliminates a huge amount of the cognitive load I experience trying to do front-end stuff. I allows me to stop thinking in state machines, and just write straight-line code. If you've been primarily a backend person and have always sort of hated doing front-end stuff, check out React and see whether it's just the programming model that's been bugging you.
* Unlike the author, I've always been more of a programming person than an HTML/CSS person; I would kind of rather eat a bug than fiddle with CSS. One thing that makes React so nice for me is that you can just buy an HTML template and gradually turn it into JSX to "animate" it into a UI. Another thing is that it so nicely decomposes into components that there are a bunch of high-quality UI component libraries to draw from.
I have a lot of the same problems with React that everyone else does:
* "This" and the JS class model still feel like own-goals and I'm regularly tripping over them. But I'm never stumped by them; the bugs are always pretty obvious and easily fixed.
* Perf has been an issue, particularly memory consumption. But to me, this just suggests that I'm actually productive in React, that I'm getting to the point where I'm comfortable enough belting out code that I'm generating perf problems to go fix. (This has come up on relatively complicated UI projects, like the debugger interface we did at Starfighter, which was a monstrosity).
* The tooling was a disaster before create-react-app. But now there's create-react-app, so the tooling isn't a problem.
* I still have no idea what the right way to test things is.
I'm not rebutting the article at all! Different people, different issues. I just thought, if that perspective was valuable, mine might be too.
But what happens when you inevitably need to step outside the boundaries set by create-react-app? From that perspective, it simply delays the problem, rather than solving it.
I had a gulp build process I used before create-react-app; it was gross to get working, but then worked just fine. I could live without create-react-app, but why would I?
A lot of the time, simply using react-app-rewired is sufficient in place of ejecting, especially if the only thing you need are some Webpack plugins.
For me personally it would be exasperating to learn all of the stuff that CRA bootstraps before actually getting to learn React.
Been working on a real-world c-r-a based project for 8 months and this is yet to happen. And the upgrade process has been a dream (update 1 dependency), no breakages so far.
In fact I now regret my other attempts to go off the rails (adding Sass), it wasn't worth it.
I normally suggest eschewing the javascript class model in favor of using stateless functional components.[0] I've found them simpler to understand and it cuts down on unnecessary typing. I almost never use 'this' in javascript, and instead have favored an OLOO[1] or pure functional style as it fits into a simpler mental model for how things are working.
I normally only test the actions that modify state in my javascript applications. I care that I'm correctly changing the state of my application, not what that state renders. (This is similar to rails apps not typically testing html output) I normally use mocha[2] for testing and if something goes wrong I can open up a normal chrome js debugger using the --inspect-brk flag when running via the cli.
You will eventually find yourself needing to support multiple routes in your react applications. Most people would recommend the "react-router" library, but I've found a lot more success with "redux-little-router"[3]
[0]: https://reactjs.org/docs/components-and-props.html
[1]: https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
[2]: https://mochajs.org/
[3]: https://github.com/FormidableLabs/redux-little-router
So I do this whenever possible, but the way this advice is worded (both here and often in the wild) makes it sound like you can just use them everywhere.
Most UIs have state. I can't imagine a UI that doesn't. Every third component or so I write I end up using classes for, so I've got a mix of classes and functional components throughout the codebase. Do you _never_ use classes? If so, what do you do instead? Otherwise if you're like me, you get to use functional components occasionally which is nice, but are nowhere near being able to get rid of the class syntax.
- Only add the `ownProps` argument to `mapState` or `mapDispatch` if you actually need it, because `connect()` will now call those functions more often (whenever the incoming props have changed). If you're not actually _using_ values from `ownProps` in there, don't add those arguments.
- The `mapDispatch` function isn't doing anything at all in that example, and can be omitted completely
- I personally recommend using the "object shorthand" form of `mapDispatch` instead. To me, there's never actually a good reason to write a separate `mapDispatch` function. Just write action creators, and pass them in an object to `connect`, like this:
Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle.
For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out!
[1]: https://github.com/supasate/connected-react-router
Redux on the other hand was a little more confusing for me to learn (the concept makes complete sense, it's the implementation and debugging that gets confusing). The great thing about Redux is that you don't have to use it or learn it. The React ecosystem is pretty well decoupled so you can choose how you want to manage state and async tasks. That is it's biggest selling point for me personally.
My experience with front-end frameworks started with Backbone + a ton of jQuery to AngularJS to React (with many different state management libraries). I found that Backbone didn't really provide much on top of jQuery + lodash/underscore, but I liked that it didn't make too many decisions for you. Angular (v1) on the other hand, forces you into some unconventional patterns (ie: the whole service vs factory fiasco and it's own dependency management system). It's fine if you aren't using a separate dependency management library (or ESM), but if you are, you have to declare dependencies twice. Angular 2/4/5/whatever-arbitrary-number-they-are-on-now has been way more confusing for me to learn as they make you learn their own templating language for things like loops, control flow, etc and still have some weird patterns around dependency injection. JSX is a lot simpler if you know basic JS. React seems to have the least amount of boilerplate code as well especially if you make use of functional components.
At my company, we use cucumberjs (https://github.com/cucumber/cucumber-js) to write scenarios for basic front-end testing. I wouldn't go overboard and start writing test to measure padding or font sizes, but you can easily see isolated scenarios and write automated tests to simply verify that a react component actually put the right element in the dom or to check conditional class names.
We also unit test many of our Redux reducers which is pretty simple with any unit testing library. Just create an initial state and expected state, call the action creator, and deep compare the new state with the expected state.
What I do wonder about is inline styling in JSX that I encounter so much in React code.
It feels "wrong" to me as inline styling has been considered a "bad" thing forever.
Among React pros is inline styling not considered a code smell?
Shouldn't style live nicely in CSS files?
Disclosure: I learned some Haskell before Elm so I may be "immunized" against some of the struggle!
For building understanding and mental models, I think it can be bad to jump into things that are too much of a struggle.
However the best of both worlds is some kind of tutorial that explains it really well. Like the recent "explaining functional programming to my 6 year old" article. Then you can dive straight in, but get off to a solid start.
Also, Svelte is easier to work with. A simpler API, Computed Properties, events. The Svelte Store is also nice. I'm forced to use React in a project, but I prefer to use the Svelte Store opposed to Redux or MobX.
HTML, js and CSS aren't separate concerns. Each component is a separate concern.
This is one of the questions I ask at every interview I do now when looking for a new gig:
"Do you prefer one JS framework does it all like AngularJS, or do you like to mix and match your JS libraries like taking ReactJS and combining it with say AmpersandJS, BackboneJS, etc?"
This is where we are. One group wants to use ReactJS and add complexity as they need it. Others just want a complete framework (however complex, and let's be honest, Angular is pretty complex!) out of the box. I've always been happy with full stack frameworks out of the box for several reasons, but it's what I prefer.
I'd be interested to know where all of this ends up in the next 18 months though.
I was discussing this with another developer who had the same sort of impression - it seems like it should be simple, conceptually, but there are a myriad of details to keep track of to keep the build system happy, to keep the components happy, to keep JSX happy. Compared to learning Vue, the whole process is much more difficult.
My approach to React was similar to Brad's, as I am far more proficient with HTML and CSS than JavaScript. I'd done plenty of wacky stuff in jQuery, and that tutorial demonstrated how React can iron out some of the problems that spaghetti jQuery can create.
I'll also add that part of the problem with wading into React is that, if you're a certain kind of frontend designer, you remember the browser wars, and you would often wait until tech was mature before you went out and used it in production. But React was adopted quickly and has changed quickly. React Native is even worse in that regard. So even if you learn how to do something a certain way, that knowledge could be obsolete in a year, or less.
But React is a tool for building complicated UI's, and overwhelmingly complicated UI's are requirements for startups, corporations and organizations, not personal sites or small toys. So like many other technologies, this one is perhaps best learned on the job, and it doesn't need to be optimized for the hobbyist.
That being said, losing the hobbyist comes with serious costs to community and innovation, a fine balance needs to be found.
That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very well.
As of now, I have still yet to see a JS framework that made any sense to me. They're all really weird to me and solving problems I've never had with UI development, or regressing previous best practices in ways I don't think make any sense.
I'd much rather just use template rendering than this stuff most of the time. At least with that, you're just using Real JavaScript (TM) and you don't have to learn some new special HTML attribute based language.
I think there's plenty of more opportunities in state management, CSS management, application structure, tooling, and making those more simple, but generally I think the view layer is more or less solved.
The new paradigm would be the browser handling all that and there is no need for frameworks anymore. We are not there yet given how poor web component support is : https://caniuse.com/#search=web%20component
I've had my whimsical entries into experimenting with Web Components, but they just haven't felt like they're quite there—ignoring the lack of support. They're workable, but I think design patterns surrounding current paradigms might need more readily addressed. As they are, you'd probably want a framework on top of Web Components to improve the semantics and just make working component state in generally less verbose.
I have a hastily-written example here playing with them:
https://robert-fairley.github.io/es6-webcomponents/
(No repo, it's not worth it. Just check the source–it's short enough)
We now see languages targeting the browser, and the beginnings of front end frameworks being developed in traditionally backend languages. I think this is going to create quite a different landscape for the web world in the next 5 years. Different languages bring different approaches to problems.
My impression of React is actually quite positive; it solves a real problem in a highly performant way and with a relatively good model. But it is still pretty low-level to me; even if you add in a dozen or so other libraries.
My needs are fairly different from Facebook or most startups -- I don't work on a single highly optimized application -- I build a new application every few months (and maintain all of the previous ones). The current set of JS frameworks don't do a lot to help me.
AngularJS 1.x + Angular-Material came close, but Google then released backwards-incompatible Angular 2.
This makes me think of an interesting/bothersome phenomenon I've seen a lot in web development (it seems to be more present here than in other domains—but I won't pretend to have any profound objectivity on the subject). People speak confidently about rationales for architectural decisions—and at first it sounds coherent and persuasive (especially paired with their confidence), but if you start trying to test it, considering specific cases, or more generally just drilling into the specific meanings of the very abstract statements—then you are likely to discover that the supposed rationale is really a justification.
I'm guessing this comes about because decisions about technology often have to be made with time constraints, and the time required to really investigate the set of viable alternatives exceeds what's available. So you're left with a partially completed search process, where the engineer has told himself a story about why choice X was the best, based on promising looking aspects of the search so far completed.
At this point, you're sort of committed to the decision you made, so you have to continue justifying it to yourself and others; and since there isn't necessarily a valid justification, the one you employ has to succeed in part through its obfuscation and your rhetoric.
Are there any that would claim that? As far as the popular ones that have been there (which is really just JQuery and Angular, but could also encompass thins like Underscore, Knockout, etc.) go, I think most of them presented themselves as band-aids for limits in Javascript/DOM API's. I think React is that first one that gained widespread adoption that actually promoted a paradigm (view is a function of state).
That is not to say it's The Final Paradigm, but I think an important reason for both Angular and JQuery to lose adoption is because the wounds they band-aided over were cured.
The basic issue with the DOM is that it makes state management a pain in the arse.
So you have written a DOM widget and you want to incorporate it in a bigger widget, so you have to have some kind of "composite" API with a widget life-cycle that pumps data and dumps custom events from/to somewhere. It's not that hard to code, but by the time you are finished coding a library that handles all that you have created you own front-end framework basically.
Web Components help a bit by it doesn't seem that Google, Mozilla or Microsoft and co are doing a very good job at promoting them, pushing them in their browsers or even education people about them. It looks like it is one of that spec browser vendors don't like for whatever reason :
https://caniuse.com/#search=web%20component
Vue.js actually retains most of the philosophy of Web Components like Polymer so I went with that instead of React,Angular and co. Front-end development is all about state management.
(ok, slight lie, there's tons of other junk inside those frameworks also, but just stay away from everything except the data binding and you'll be much happier.)