17 ms·

Master these five concepts to master React

174 points by ziodave 10y ago

k__ 10y ago
These and 3rd party integration, I think. HOC aren't to bad to know either, if you want to end up with maintainable code. shameless plug: https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero
tyingq 10y ago
Would you put "filling in the rest of the stack" as another finger of death? There doesn't seem to be good consensus on that bit.
- peterbonney 10y ago
  Nor should there be a consensus. Back-end use cases are far more diverse than front-end use cases. Front-end frameworks should never prescribe the rest of your stack, IMHO.
  - tyingq 10y ago
    I'm not a front end expert...but the variety of choices around filling the stack for react seems broader than it was in the past. It feels like there's more risk in making the wrong choice. I see lots of regrets around redux, for example, adding more complexity than initially wanted. Or, selecting a tool that becomes abandonware, etc.
    - k__ 10y ago
      Yes, there are a bunch of regrets about Redux, but I have the feeling it got better last year. In 2015 we had countless Flux implementations and most of them have been abandoned. I did an app with Flummox, for example and switched to Redux later. But now? Redux and MobX are basically the major players and you can still do small to medium sized apps without them.
    - kls 10y ago
      Anyone who went thru the Angular debacle would certainly see it from a contrary point of view. Yes there is more risk of a particular piece of the stack being wrong and needing to be replaced but the risk is not a total rewrite of your app out of something like Angular 1. Rather it is a smaller effort such as moving your flux implementation or going from gulp to webpack. I think the modularity actually helps in long term support of an application, but you pay for it in up frot complexity and contextual understanding of all the pieces and how they bolt together.
  - garysieling 10y ago
    "Rest of the stack" also includes things like build tools, Javascript testing framework, TypeScript, etc.
    - peterbonney 10y ago
      Fair point.
whatever_dude 10y ago
Subjective content opinions aside, this article is short and to the point. Well written.
eternalban 10y ago
Components and "higher-order component factory function". Waiting for "factory factories" and an iteration of Spring in Javascript. I'm being a bit snide here since the Java community had to endure years of uninformed ridicule regarding the meta gymanstics required for component oriented programming. I remember talking to a react or backbone (or whatever, it was the current 'thing') developer 1.5 years ago and giving a brief history of GUI toolkit frameworks before browsers. I swear, his eyes lit up like I was spilling occult secrets. Back to the future, par per course in this forgetful field. [p.s. it's not just the browser side people. Many years ago I mentioned in a Go community group to take a look at the Servlet architecture (circa ~2000) and its minimal but powerful abstractions. I think it was yesterday that we had people cheering "context" in Go 1.8.]
- aalhour 10y ago
  If only people listen, think and then decide whether a technology really works for them rather than trying to catch up to some "current" thing due to some sort of a FOMO experience! On the other hand, you get to meet people all over the industry who were asked to deliver a simple Frontend app but built a new trending framework not because they had to solve a nontrivial problem but because they projected too much into the future that they thought that introducing some meta gymnastics will solve a probable UX scenario in the next 2-3 years down the product line!!!
  - paulryanrogers 10y ago
    Seems to be missing a 'not'
- unculture 10y ago
  You know, this information isn't really readily available to us user interface people. At least, it's not obvious where to go to read about it. I would love a brief history of GUI programming concepts and patterns if you could point to one.
  - eternalban 10y ago
IgorPartola 10y ago
Smart and dumb components are one of the reasons why I quickly jumped ship to Vue. It's too complicated and the starter apps make it worse. You get four level deep directory structures where each dir contains a single file of like five lines. It feels like knitting a castle. Vue certainly has its own cruft, but it's at least somewhat simpler when it comes to how components compose.
- acemarke 10y ago
  The "container/presentational" component pattern is completely optional. If you want to write components that both fetch and display data, that's entirely up to you. Dan Abramov, who wrote the most widely referenced post discussing the topic ([0]), recently said that he somewhat regrets writing it because many people have assumed it's a strict rule that must be followed ([1]). That said, it _is_ a very useful pattern, and can help with conceptual management of components. I have links to a number of additional articles discussing this pattern as part of my React/Redux links list ([2]). [0] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... [1] https://twitter.com/dan_abramov/status/802569801906475008 https://twitter.com/dan_abramov/status/802569801906475008 [2] https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories https://github.com/markerikson/react-redux-links/blob/master...
  - IgorPartola 10y ago
    Thanks for the perspective. I guess I ran into this very thing. React itself is actually a pretty simple library. The problem is that it's not the whole story, so you need other bits and pieces to put together a functional SPA. Ender redux, react-router, etc. And because React tries to explicitly not be so opinionated about what you should use, the way you learn about this stuff is not from the official tutorial, but from various blog posts. There are also resources like this: https://github.com/kriasoft/react-starter-kit https://github.com/kriasoft/react-starter-kit. On the surface it's great. But for my taste it's organized very poorly. You have all your reusable (NB: reusable != reused) components in one place, and all your pages in another. Each component consists of exactly 3 files that are 3 directory levels down. Pages (views? containers?) are in a separate directory structure where each page consists of 3 files that are 3 directory levels down. I guess if your SPA consists of hundreds of pages/views/containers with most components reused many times this makes sense. For my applications (low dozens of pages/views/containers) this seems like a huge overkill. And don't get me started on the redux theory of all global state all the time, which actually seems to not be ideal for things like "I just want a more complex <select>", and you have a very scattered learning curve. By contrast, Vue has a pretty sane slightly opinionated learning curve. Sure, there are a few things you need to figure out (XHR/Websockets + VueX + promises don't have a decent recipe in the docs), but overall it's much more coherent.
rquestion 10y ago
React best practises question - At what level should event handlers be installed? At lowest level components or the highest level? How are events in React supposed to be propagated from low level components to their parent components when the low level components should not have any knowledge of their parents?
- Cafey 10y ago
  You may want to have a read at Redux (http://redux.js.org http://redux.js.org) or any Flux type of container. Basically, you don't propagate directly to your parent. In React there should be only one source of truth. So in your case, the event in a low level component should emit an action that will modify data in your Store/Container/Model. Then this change will be passed down (with the correct setup) as props to all of your components. >React best practises question - At what level should event handlers be installed? At lowest level components or the highest level? I personnally prefer when the handlers are close to the associated JSX. I doubt there is any requirement on this other than maintainability.
  - rejschaap 10y ago
    I don't think it is a good idea to drag Redux and Flux into the discussion when someone asks a basic question about React.
    - kls 10y ago
      I think that depends, many would argue that a flux implementation is an easier way to reason about the problem set, thus their existence. Making someone aware that this is what flux implementation where designed (in part) to address, allows them to see the full scope of possible ways to accomplish their goal. I see nothing wrong with saying "hey that is why these guys built this library". He was asking for best practices, certainly a sizable amount of developers would argue to use a flux implementation for that particular problem, as a best practice.
      - rejschaap 10y ago
acemarke 10y ago
If anyone's interested in learning React, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
drivingmenuts 10y ago
> the component approach means that both HTML and JavaScript code live in the same file. Something about this makes me want to facepalm and wonder why we bothered with separation of concerns, when React just undoes all of that.
- prof_hobart 10y ago
  That's exactly what I thought when I started using it. But as I've got more used to it, I'm not sure it's really an issue, or at least doesn't have to be. Firstly, JSX isn't really HTML. It's a bit of syntactic sugar around JavaScript "createElement" functions. If you don't want to have something that looks similar to HTML in your JS, you don't have to. Secondly, if you want dynamically generated HTML, you're going to need some form of logic embedded in there somewhere (loops, conditionals etc). Most template languages end up with their own directives, like Angular 2's "ngFor". The React answer is to use standard JavaScript for that control. And if you then want to separate out the non-display logic, you can use a combination of "smart" (pure JS logic) and "dumb" (JS/JSX display) components, and treat the JSX files as templates. "Separation of concerns" in this context isn't about not mixing code and markup, it's about not mixing business and display logic, and there's nothing in React that stops you doing that.
deleted 10y ago
[deleted]
tonyneel923 10y ago
Good article besides the nonsense about some of the react lifecycles being voodoo. You will use it if you program extensively.
beebeebush 10y ago
Best concept I recommend strongly is to read license and trying to understand it fully. ..and realize that Facebook could sue your company to use react

174 points by ziodave 10y ago

k__ 10y ago

These and 3rd party integration, I think. HOC aren't to bad to know either, if you want to end up with maintainable code. shameless plug: https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero

tyingq 10y ago

Would you put "filling in the rest of the stack" as another finger of death? There doesn't seem to be good consensus on that bit.

peterbonney 10y ago
Nor should there be a consensus. Back-end use cases are far more diverse than front-end use cases. Front-end frameworks should never prescribe the rest of your stack, IMHO.
- tyingq 10y ago
  I'm not a front end expert...but the variety of choices around filling the stack for react seems broader than it was in the past. It feels like there's more risk in making the wrong choice. I see lots of regrets around redux, for example, adding more complexity than initially wanted. Or, selecting a tool that becomes abandonware, etc.
  - k__ 10y ago
    Yes, there are a bunch of regrets about Redux, but I have the feeling it got better last year. In 2015 we had countless Flux implementations and most of them have been abandoned. I did an app with Flummox, for example and switched to Redux later. But now? Redux and MobX are basically the major players and you can still do small to medium sized apps without them.
  - kls 10y ago
    Anyone who went thru the Angular debacle would certainly see it from a contrary point of view. Yes there is more risk of a particular piece of the stack being wrong and needing to be replaced but the risk is not a total rewrite of your app out of something like Angular 1. Rather it is a smaller effort such as moving your flux implementation or going from gulp to webpack. I think the modularity actually helps in long term support of an application, but you pay for it in up frot complexity and contextual understanding of all the pieces and how they bolt together.
- garysieling 10y ago
  "Rest of the stack" also includes things like build tools, Javascript testing framework, TypeScript, etc.
  - peterbonney 10y ago
    Fair point.

whatever_dude 10y ago

Subjective content opinions aside, this article is short and to the point. Well written.

eternalban 10y ago

Components and "higher-order component factory function". Waiting for "factory factories" and an iteration of Spring in Javascript. I'm being a bit snide here since the Java community had to endure years of uninformed ridicule regarding the meta gymanstics required for component oriented programming. I remember talking to a react or backbone (or whatever, it was the current 'thing') developer 1.5 years ago and giving a brief history of GUI toolkit frameworks before browsers. I swear, his eyes lit up like I was spilling occult secrets. Back to the future, par per course in this forgetful field. [p.s. it's not just the browser side people. Many years ago I mentioned in a Go community group to take a look at the Servlet architecture (circa ~2000) and its minimal but powerful abstractions. I think it was yesterday that we had people cheering "context" in Go 1.8.]

aalhour 10y ago
If only people listen, think and then decide whether a technology really works for them rather than trying to catch up to some "current" thing due to some sort of a FOMO experience! On the other hand, you get to meet people all over the industry who were asked to deliver a simple Frontend app but built a new trending framework not because they had to solve a nontrivial problem but because they projected too much into the future that they thought that introducing some meta gymnastics will solve a probable UX scenario in the next 2-3 years down the product line!!!
- paulryanrogers 10y ago
  Seems to be missing a 'not'
unculture 10y ago
You know, this information isn't really readily available to us user interface people. At least, it's not obvious where to go to read about it. I would love a brief history of GUI programming concepts and patterns if you could point to one.
- eternalban 10y ago

IgorPartola 10y ago

Smart and dumb components are one of the reasons why I quickly jumped ship to Vue. It's too complicated and the starter apps make it worse. You get four level deep directory structures where each dir contains a single file of like five lines. It feels like knitting a castle. Vue certainly has its own cruft, but it's at least somewhat simpler when it comes to how components compose.

acemarke 10y ago
The "container/presentational" component pattern is completely optional. If you want to write components that both fetch and display data, that's entirely up to you. Dan Abramov, who wrote the most widely referenced post discussing the topic ([0]), recently said that he somewhat regrets writing it because many people have assumed it's a strict rule that must be followed ([1]). That said, it _is_ a very useful pattern, and can help with conceptual management of components. I have links to a number of additional articles discussing this pattern as part of my React/Redux links list ([2]). [0] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 https://medium.com/@dan_abramov/smart-and-dumb-components-7c... [1] https://twitter.com/dan_abramov/status/802569801906475008 https://twitter.com/dan_abramov/status/802569801906475008 [2] https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories https://github.com/markerikson/react-redux-links/blob/master...
- IgorPartola 10y ago
  Thanks for the perspective. I guess I ran into this very thing. React itself is actually a pretty simple library. The problem is that it's not the whole story, so you need other bits and pieces to put together a functional SPA. Ender redux, react-router, etc. And because React tries to explicitly not be so opinionated about what you should use, the way you learn about this stuff is not from the official tutorial, but from various blog posts. There are also resources like this: https://github.com/kriasoft/react-starter-kit https://github.com/kriasoft/react-starter-kit. On the surface it's great. But for my taste it's organized very poorly. You have all your reusable (NB: reusable != reused) components in one place, and all your pages in another. Each component consists of exactly 3 files that are 3 directory levels down. Pages (views? containers?) are in a separate directory structure where each page consists of 3 files that are 3 directory levels down. I guess if your SPA consists of hundreds of pages/views/containers with most components reused many times this makes sense. For my applications (low dozens of pages/views/containers) this seems like a huge overkill. And don't get me started on the redux theory of all global state all the time, which actually seems to not be ideal for things like "I just want a more complex <select>", and you have a very scattered learning curve. By contrast, Vue has a pretty sane slightly opinionated learning curve. Sure, there are a few things you need to figure out (XHR/Websockets + VueX + promises don't have a decent recipe in the docs), but overall it's much more coherent.

rquestion 10y ago

React best practises question - At what level should event handlers be installed? At lowest level components or the highest level? How are events in React supposed to be propagated from low level components to their parent components when the low level components should not have any knowledge of their parents?

Cafey 10y ago
You may want to have a read at Redux (http://redux.js.org http://redux.js.org) or any Flux type of container. Basically, you don't propagate directly to your parent. In React there should be only one source of truth. So in your case, the event in a low level component should emit an action that will modify data in your Store/Container/Model. Then this change will be passed down (with the correct setup) as props to all of your components. >React best practises question - At what level should event handlers be installed? At lowest level components or the highest level? I personnally prefer when the handlers are close to the associated JSX. I doubt there is any requirement on this other than maintainability.
- rejschaap 10y ago
  I don't think it is a good idea to drag Redux and Flux into the discussion when someone asks a basic question about React.
  - kls 10y ago
    I think that depends, many would argue that a flux implementation is an easier way to reason about the problem set, thus their existence. Making someone aware that this is what flux implementation where designed (in part) to address, allows them to see the full scope of possible ways to accomplish their goal. I see nothing wrong with saying "hey that is why these guys built this library". He was asking for best practices, certainly a sizable amount of developers would argue to use a flux implementation for that particular problem, as a best practice.
    - rejschaap 10y ago

acemarke 10y ago

If anyone's interested in learning React, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.

drivingmenuts 10y ago

> the component approach means that both HTML and JavaScript code live in the same file. Something about this makes me want to facepalm and wonder why we bothered with separation of concerns, when React just undoes all of that.

prof_hobart 10y ago
That's exactly what I thought when I started using it. But as I've got more used to it, I'm not sure it's really an issue, or at least doesn't have to be. Firstly, JSX isn't really HTML. It's a bit of syntactic sugar around JavaScript "createElement" functions. If you don't want to have something that looks similar to HTML in your JS, you don't have to. Secondly, if you want dynamically generated HTML, you're going to need some form of logic embedded in there somewhere (loops, conditionals etc). Most template languages end up with their own directives, like Angular 2's "ngFor". The React answer is to use standard JavaScript for that control. And if you then want to separate out the non-display logic, you can use a combination of "smart" (pure JS logic) and "dumb" (JS/JSX display) components, and treat the JSX files as templates. "Separation of concerns" in this context isn't about not mixing code and markup, it's about not mixing business and display logic, and there's nothing in React that stops you doing that.

deleted 10y ago

[deleted]

tonyneel923 10y ago

Good article besides the nonsense about some of the react lifecycles being voodoo. You will use it if you program extensively.

beebeebush 10y ago

Best concept I recommend strongly is to read license and trying to understand it fully. ..and realize that Facebook could sue your company to use react