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 laye…
You might want to go read the release notes for React 16.3 ( https://reactjs.org/blog/2018/03/29/react-v-16-3.html ), which discuss the history of the old context API, and its new replacement. 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/re…
Absolutely. That'll go in lockstep with upgrading to 16.3 :)
The problem that I have faced repeatedly in the past is whenever I try to follow a tutorial, most of the time things don't work because React/other react libraries change so frequently and articles get outdated very quickly.
Where can I learn react and its other components if so far my only experience is in javascript and Jquery(similar experience as point 1, 2 and 3 in the article).
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 ti…
No.
For anyone else covering the same dilemma and doesn't care about transitions:
(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.
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.…
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 ye…
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:
Switching from Redux to Mobx dramatically decreased my mental load. It is much more straight forward.
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?
> functional, immutable
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.
>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 funct…
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 {name} } function mapState(state, ownProps) { r…
I see. I don't really have a need for redux but that clarifies things.
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 t…
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…
> 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.
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 t…
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 be…
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.
My skill set used to be very similar to Brad's. I followed his blog for years and learned a lot from him. Several years ago, I decided that there seemed to be better jobs for people who could write JavaScript, so I started teaching myself. The learning curve was insanely difficult. There were so many tools, syntaxes and buzzwords that I had to navigate and on top of that, it felt like things were changing every week. I'd post a question on StackOverflow or IRC about how to do x, and the answer would be that first I had to do a-w. I feel like this is what Brad is going through now. But by the time I got to learning React, I had already been writing ES6 for over a year and I had figured out the worlds of Grunt, gulp, Webpack, Babel, etc. And I knew some fundamentals like functional programming. Having all of that background made React extremely easy. I've never felt that I've used a technology or framework that's so easy and straightforward. Redux took a little bit more effort for me to wrap my head around, especially when trying to sync application state with a database, but I think that's difficult for a lot of people, which is part of the problem that things like GraphQL and Apollo solve. And even though Redux was more challenging, I found it to be a really useful pattern that ultimately helped me keep apps way more organized as they grew. All of that being said, I empathize with people who are trying to learn all of the parts of being a developer from ant high level entry point like React. There are a lot of contextual things that you have to know first and it can be overwhelming to someone who hasn't yet had the opportunity to learn those things. The biggest problem, in my opinion, is that things in the JavaScript world are moving so fast and the APIs for things are changing faster than people can keep up. I can't remember the last time I read Getting Started docs or examples that weren't already outdated by the time I was trying them out.
I think the way developers tend to think about front-end is misguided. Front-end development can be just as complex as backend, and IMO is analogous to iOS / Android, but interacting with a different environment.
Having started in ASP.NET web forms, I wholly welcome React & Redux / etc., because those were painful years.
Also, in many cases, developers are paid quite well ( a doctor like salary in some cases). I don't see problems with the notion of "having to keep up with the industry" since we're paid so well to do so.