1. 12
  1.  

  2. 14

    I think that graph would be a lot more useful with some competitors for context.

    Anyways, I mostly submitted to talk about how the “taking over” feels as I’ve been doing React the last month or so. As in this example, adding a first component to a page feels a little clunky until it’s updating, then it’s sort of magical. The second or some sub-components are really a breeze.

    But! React is intensely tied to the DOM and hierarchically-oriented. So the moment you want to have two components that interact with each other (perhaps fetching/posting data in bulk), React requires that they share a parent component or one be the parent of the other.

    Instead of trying to sync the state between different components, you should rely on the top-down data flow.

    Because “The Data Flows Down”, if the two interacting components are widely-separated on the page (say, the row of a message in your inbox and a header indication of new messages), React wants you to have a top-level component owning and directing that data through the entire page. And because a component in a sense is a DOM element, it wants to own the rendering of the page as well. You get a finger-wagging (but informative) error message if you try to have one component update another from its render.

    So my React experience has been:

    • Week 1: Huh, this is weird. I wish the docs weren’t an afterthought.
    • Week 2: OK, this makes sense, and it’s a great solution to jQuery soup.
    • Week 4: Damn, either I have a stop-the-world rewrite of everything or a godawful hack.
    1. 6

      Week 4: Damn, either I have a stop-the-world rewrite of everything or a godawful hack

      Full disclosure: I am not a pro frontend programmer, but I’ve tried many frameworks and libraries (following their guidelines and philosophies), and I always end up at this stage :-( I just stopped doing frontend for fun and went back to server rendered apps.

      1. 3

        React wants you to have a top-level component owning and directing that data through the entire page.

        You might have tried these by now but the whole idea behind Flux/redux is to decouple app level state from components/DOM.

        What do you think of that approach?

        1. 1

          I’ve done about 18 months of work with react, some with flux and some without.

          I would avoid flux until well after you are sure you need it.

          There are much simpler patterns that solve most of the same problems.

          1. 1

            I’m looking at it and will probably fall into it. I’m reluctant because of the high complexity and generally poor documentation I’m finding, but it looks like the only viable choice for my environment.

          2. 2

            I don’t know what your constraints are, and I don’t want to be the “re-write it in X” guy, but have you looked at Elm at all? I’ve found the process of building out apps in small pieces with it to be much like your description of working with React, but it’s not constrained to the component approach. I haven’t built anything large enough with it to say whether or not it has the same “Week 4” issue, but I’d suspect it’s much easier to go from “godawful hack” to well-structured code thanks to the type system and excellent compiler messages. All told, I’m quite impressed with it so far. It seems to have many of the same advantages as React, without some of the pitfalls that come with JS. All of that comes at the cost of a learning curve that’s a bit steeper, and a less robust set of libraries to draw from.

            Caveat: My React and Elm projects have all been fairly small and narrow in scope.

            1. 2

              My constraints are that I don’t get to pick the technology on this one.

              1. 2

                That’s fair. In that case, I suppose I’ll re-frame my comment to something along the lines of “If you come away from this project mostly liking React, but finding shortcomings with it, maybe look at Elm next time you get to pick the tech.”

                I’d also second @sridatta’s comment below recommending Redux if it’s not something you’re using already. I think it could be a clean path for resolving the issue with disparate components that need to update based on the same logical state. I haven’t tried mixing it with stateful React components, but I think it wouldn’t be too difficult to bring it in for a portion of the app, and gradually grow it out to be the primary manager of application state over time.

              2. 1

                Hijacking this comment to offer another option: https://workiva.github.io/over_react/

                Basically a statically typed wrapper around React using Dart. It’s pretty slick. I can also be used with a Flux-like library (https://github.com/Workiva/w_flux).

                I personally like Dart a lot, not everyone does. I also like Elm. It finally feels like we have “good” choices for front end development :-)

              3. 1

                Sounds like you need better state managing. You should check out redux if you haven’t yet.

              4. 1

                Now i have might to learn one more JS framework. This never ends. Sigh. Seriously back to backend and api development. JS will make me crazy now. Just too many of them.

                1. 1

                  I think that the trend is going to change due the recent PATENTS file decision. Many companies can’t use React due to it, and that number is probably going to increase.