1. 8

  2. 5

    This example doesn’t fit with the React style I’ve seen before, where state is rarely used. This data isn’t flowing like I’ve come to expect, but one of my biggest gripes with React is that the docs are no longer very good because they haven’t been comprehensively rewritten for the current design and because the only sentence in the docs to address the crucial distinction between props and state is the distinctly unhelpful:

    If you imagine a component tree as a waterfall of props, each component’s state is like an additional water source that joins it at an arbitrary point but also flows down.

    In this post’s example, I would expect to see a component for an individual Person with the props name and location, then a People component storing the ordered list in props. If the app does a lot of this general “maintain a sorted list with random insertions from over the net”, People would be wrapped by a higher-order component managing that. Otherwise there’d probably be a page-level custom component or just random stateful javascript pulling in the data and passing it down to People for rerendering. (I don’t know Redux to address the second half of his example.)

    It’s ironic that the author advocates for immediate mode GUIs, because normal React looks and works like an immediate mode GUI with memoization. A component is a function responsible for part of the page. Its props are the input to the function and it returns a render of part of the page (possibly by rendering more memoized components). The cache is busted when props changes. There’s also a hack to be used sparingly called state so that small bits of UI state can be managed at a low-level instead of in their parent component.

    1. 4

      The core idea of React is very elegant and a bit of a paradigm shift in UI implementation: full-pass stateless rendering. The problem is that React wants you to do purely functional programming on a platform that was not really designed for it, which at the end of the day makes complex use cases cumbersome to implement. The future of web rendering engines is incremental render.

      1. 4

        Indeed, the concepts behind React are solid, and using it in a functional language is very pleasant. My team has been working with the Reagent http://reagent-project.github.io/ ClojureScript library that’s built on top of React. None of these problems exist there. You don’t have to worry about mutation because you have persistent data structures, you don’t have to worry about component lifecycle, props, and so on. All the complexity just goes away and you can focus on actually building your app.

        1. 3

          I concur, moving from a reagent app to a React app written in JavaScript has shown me how boilerplate-y and cumbersome React is in its “native” environment.

        2. 2

          I only used react for a few months, but I recall that it had a few nonsensical design decisions, like if you nest multiple objects, every object gets access to the entire global state instead of some substate that corresponds to their position in the object tree. This makes it extremely cumbersome/impossible to have clean, compositional designs. Otoh, I remember Elm did this exactly right, and having truly compositional components was very easy.

        3. 2

          Doesn’t this post reduce to “argh browsers, DOM is really heavy, argh”? In which case, yeah, sure, but …

          1. 2

            Clearly, the solution is for the DOM to suck less and become fast :)

            1. 2

              The slowness of the DOM is greatly exaggerated. And with Custom Elements you can literally use the DOM as your component model :)

            2. 1

              If we solved the original issue (maybe that the DOM is slow and possibly the wrong solution) then the need to do all this extra work would disappear.

              It seems like such a good idea…

              I wonder if the author’s underlying complaint could be addressed by having React components subscribe to variables (not sure how to do references in JavaScript in a general way but that would be part of the implementation, in some form or another) and then every 60th of a second pulling all the variables and re-rendering. The diffing and shadow DOM would work as before. (The net effect might be that we have copies of all the data, though.)

              1. 1

                I recommend freezer for trees of immutable data. Completely avoids the WRITE LOTS OF CODE part!