pepopowitz’s Twitter Archive—№ 1,307

React hooks look neat (reactjs.org/docs/hooks-intro.html). I think they improve readability a ton. Also, it felt weird creating classes just to manage state. Some thoughts about how I'd test components that are using hooks, without having actually played with code:
Permalink On twitter.com 2018 Oct 26 Mood 0

…in reply to @pepopowitz
1a. useState() hook: State mgmt is an implementation detail. The user doesn't care whether you're using setState, useState, context,... In most cases involving state mgmt, there is an associated interaction in the component/browser. That's what I'd test with useState.
Permalink On twitter.com 2018 Oct 26 Mood -2 🙁

…in reply to @pepopowitz
1b. i.e. render the component, click a button that calls the modifier from useState, then verify that the expected UI change occurred.
Permalink On twitter.com 2018 Oct 26 Mood 0

…in reply to @pepopowitz
2a. useEffect() hook: useEffect seems like it is useful when you have a side-effect associated with the component. A non-React DOM change, or something.
Permalink On twitter.com 2018 Oct 26 Mood +2 🙂

…in reply to @pepopowitz
2b. In this case, I'd render the component, and test that the side-effect occurred. The hooks docs use "change the document.title" as an example - I'd verify that when I rendered my component, the document.title got changed in the DOM.
Permalink On twitter.com 2018 Oct 26 Mood -2 🙁

…in reply to @pepopowitz
3a. useContext() hook: This kind of falls under the "state mgmt" style of hook. The user doesn't care you're using context; they care what happens when the state changes.
Permalink On twitter.com 2018 Oct 26 Mood +2 🙂

…in reply to @pepopowitz
3b. At a "unit" level, we could render a component, then modify the context, then make sure the appropriate UI change occurred in the component. I'm not sure how valuable this test would be, & it seems a little like testing implementation (❗️the test would be altering context.)
Permalink On twitter.com 2018 Oct 26 Mood +4 🙂

…in reply to @pepopowitz
3c. Probably a more useful test is at a "unigration" level - render an entire subtree of components that included the context from top to bottom - then verify that the consumer is affected properly when the user takes an action that modifies the provider's value.
Permalink On twitter.com 2018 Oct 26 Mood +3 🙂

…in reply to @pepopowitz
4. custom hook: These seem like compositions of other types of hooks. I'd probably have my test create a component that utilized the custom hook, then verify that any of the expected things previously named in this thread occurred.
Permalink On twitter.com 2018 Oct 26 Mood +2 🙂

…in reply to @pepopowitz
In the end, it kind of looks to me like testing my components wouldn't change a whole lot whether I was using hooks or not using hooks. I guess this makes sense, since the hooks are an implementation detail, and I try to avoid testing implementation details.
Permalink On twitter.com 2018 Oct 26 Mood +3 🙂

…in reply to @pepopowitz
There are lots of other types of hooks (reactjs.org/docs/hooks-reference.html), but (a) I'm not totally sure how much I'd use them, and (b) I haven't figured out yet how I'd test them. Anyone have thoughts on them, or any of the above?
On twitter.com 2018 Oct 26 Mood 0