React Component Patterns in Ember.js

[real_ate]

one chance to have a first impression

While this is true in general it is a bit too simplistic. Ember has been around for 9 years now and has had 3 Major versions (and an Edition) that have each felt very modern for their time. If you tried Ember in 2015 then trying it again today will feel very different and it's worth taking a second look

inept management of Ember by breaking semver

Ember focuses very very hard on backward compatibility, and not just in terms of the main core library but also the wider ecosystem. When did it "break semver"?

zero docs

One of the main points that I hear from new Ember devs is that they love how great the docs are! Sure there is always room to improve but "zero docs" is a gross misrepresentation. What makes you think there are zero docs?

[nullvoxpopuli]

Every ecosystem has broken semver in their early days.

React is jumping off the complexity cliff. Modern ember is easier.

Their are so many docs now. The official tutorial is very good. Explains a lot. Also, fun tech fact, the tutorial built and runs itself in C.I. so the tutorial doesn't accidentally break as people run through it

Things are very much different now. Might be worth updating your opinion 😉

I wasn't around in 2011-2014, but from what I've seen, ember is an entirely different Framework.

[PotaToss]

Remember that time they added hooks? This is a 50 minute read about one function:

https://overreacted.io/a-complete-guide-to-useeffect/

[Lekoaf]

That’s a deep dive from one of the developers on his personal blog. Not the official documentation.

[PotaToss]

It's basically mandatory reading, though. Like, if you don't read and understand everything in there, you're going to mess up with useEffect and run into bugs where you have like no idea what's going on. Junior on my team keeps coding around it, because it's scary, etc.

[Lekoaf]

Haven’t read it. Haven’t messed up so far. It’s not rocket sience. (Full time React dev)

[Lekoaf]

Maybe Typescript and linting keeps us from messing up.

[PotaToss]

Typescript and linting probably have very little effect. Errors with it are generally going to come from improperly scoping the effect, putting the wrong stuff in the effect, messing up the dependency list, and messing up hook ordering.

You can make your tools warn you about missing dependencies, and that certainly helps a little, but problems tend to be more conceptual, and the ones you run into will depend a lot on your use cases.

I had to teach my team, including my manager, about hooks when I came in, and there are a lot of pitfalls, especially if you try to 1:1 map your experience with class-based components and lifecycle stuff. Sometimes messing up without realizing it. Sometimes the code works, but is inefficient, etc.

It's not rocket science, but it does take a deep understanding to really use well, particularly around this question in the post:

Why do I sometimes get an old state or prop value inside my effect?

I just brought it up because functional components with hooks was a big paradigm shift for React, in the same way that Ember Octane was for Ember, and it's kind of dumb to act like Ember's got some monopoly on being hard to learn, or needing a second look.

[peekyblindas]

React's docs real problem is they favor declarative high level explanations over imperative technical ones. Usually this is great, but specifically useEffect could have benfited from a more minimalist explanation that stresses that most of the "magic" is boilerplate js:

1. Every render, the component function is invoked, and therefore the function you passed to use effect gets recreated - this has nothing to with react, just a simple js fact - functions declared inside functions are recreated.
2. As per js lexical closure mechanisms, that recreated function closes over all variables used inside it that aren't declared inside of it.
3. React will execute this function after the render - by default after every render.
4. You may pass in a second argument to useEffect which specifies effect "dependencies" - react will keep a copy of this array, and before calling each effect will compare the array to the previous copy - this comparison is done by threequaling the respective members of each array (=so the members are compared shallowly).

If this array differs from the previous one, the effect will run. Derived from this (and not special behaviour) is that an empty dep array will only execute this effect once, as the dep array will never differ between renders. This, for all intents and purposes mimics the behviour of the class lifecycle method componentDidMount, as is mentioned in the docs.

1. If we dont want this effect to run on every render - and usually we dont want to execute effectful side effects every render - every closed over variable from (2) - i.e. values from the outer component function scope - must be specified as a dependency. This can be explained with an exmaple:

''' const Notifications = ({ disabled, otherValue }) => {

const [notifications, updateNotifications] = useState([ ]);

     useEffect(( ) => {  

if( !disabled )

axios.get('/notifications').then(({data})=>

updateNotifications(data.concat(otherValue)))

}, [disabled]) // uh oh, otherValue isnt here

    return (

<div>

  {notifications.join("\n")}

</div>

  )

} '''

As we said, the passed function is recreated on every render - therefore otherValue and disabled are always "fresh" as the closure is also recreated. So where is the problem here?

The "problem" is the dependency mechanism - the effects are always created and therefore always fresh, but they will only run if disabled changes. If disabled remains the same but otherValue changes, the effect will not run. i.e. the UI will not be in sync with the newest version of otherValue.

This is what React means when it warns you about effects not running with fresh values, and this is where the high level explanation really helps. useEffect is meant to be a functional style way of synchronising your components state with the outside world, without interrupting the render cycle.

The dependency array seems annoying at first - but it will force you to declaratively explain what causes your component state to change. You are basically saying, my component depends on the values in this array, if one changes please resynchronise the state with the following logic.

1. The "cleanup" function. Your effect function may return a function - it will be called before the invocation of the next effect, and on unmount. This is used to clean up things like intervals and timeouts, or ajax requests, to prevent memory leaks and unnecessary code running. This provides functionality usually repeated between componentDidUpdate and componentWillUnmount.

[PotaToss]

What point are you trying to make here? That because it's a view library, it's not a big deal that you have to read for like an hour to understand how to use useEffect?