Re: Cognitive Loads in Programming

[peerreynders]

Hi,

Great article, Thank You! (found it via twitter)

One part, unrelated to the core topic.

Thus, the code may feel weird and opinionated (e.g. React components avoid using hooks) but it remains accessible.

Are there any references to code written is this particular style? I'm interested in the kind of trade offs that are being made, as it sounds like it's taking UI segregation seriously.

Thanks to this article I also noticed your Type Enthusiast's Notes about TypeScript series. Looking forward to squeezing every little bit of wisdom out of them.

Thank You again for taking the time to craft your blog!

Peer

[rpeszek]

Sorry for not replying earlier. I missed notification about your comment.

Think about is this way, any hook has a type, you can just add it to input parameters in your component.
This allows the code to centralize the effects (hooks) into, say, the app component or other container like thing.

E.g. a state hook

const [isFocused, setFocus] = React.useState(false)

has morally the type [boolean, (b: boolean) => void] and you could just add these to to your component and handle maintaining focus outside
(focus could be maintained in a centralized model containing all data for your app, your app could have one gigantic state hook that maintains that big model).
Note this is more testable, no need to mock things, you control focus from outside.

One warning, a big centralized model that has performance implications, especially if you react to keystrokes, so some distributing into local hooks is sometimes needed.

This approach could lead to creation of specialized components that handle certain type of hooks keeping most components pure. E.g.

<MeasurementEffect> //custom component that encapsulates some measuring and offers these to other components
 {({measurements} => 
   <MyInputComponent 
       data={data}  //data handled outside
       setData={setData}  //modifying data handled outsize
       measure={measurements.visualWidth} //custom measurement utils passed explicitly
      />
  }
</MeasurementEffect>       

The exact types and you pass in and out depend on your design but you have higher level functions at your disposal so sky it the limit.

This way, e.g. you could write tests that make your component small or big and verify how you code reacts to size but you do not encapsulate size handling and force some complex mocking to test....
The types become very explicit, you look at the type and see immediately that the component uses measurements, etc.

I have not found much written about it, it does not mean examples are not available, I just do not know of a good source.
I find coding like this natural because of my backend work.

If you start coding this way, it will become very natural to look into lenses and optics.

This lists only trivial examples:
https://rpeszek.github.io/posts/2021-12-24-ts-types-part2.html#referential-transparency

Hope that helps and answers your question.

[peerreynders]

Thank You for your response.

So apparently I misread that section of your article. Going over it again:

Experiencing different results every time the code is executed typically causes surprise, in my experience developers rarely think about this during implementation. Thus, the code may feel weird and opinionated (e.g. React components avoid using hooks) but it remains accessible.

This left me with the impression that somehow you elected to avoid hooks entirely because their state management violated referential transparency for function components.

If I understand you correctly you seem to be using a variant of the Presentational/Container component approach.

• Presentational: Referentially transparent function components that don't use hooks themselves. In particular the current state is passed via props by the container component as well as any event handlers that may update state.

• Container: Non-visual components that handle all the impure aspects (state and effects) but pass all the necessary state and handlers to the presentational components via props.

As a result hooks would only be used in non-visual container components.

Now I can see how this might simplify testing of the presentational components but for the container components additional measures may be necessary as hooks depend on React's environment. Perhaps that means factoring out any container logic as pure functions that can be tested outside of React.

[rpeszek]

I think you have a valid point, the sentence you quoted is somewhat confusing, I will clarify it. Thank you!

The link and your bullet points describe this approach well.
About testing, "container" components will be tricky to test without React. However, in my experience, decoupling presentation and various effectful hooks into separate components helps in testing of both ends.

We call these internally: pure and effects.
IMO the biggest benefit of this separation is type clarity.

[rpeszek]

To add to above reply about testing. Test benefit for pure presentation components is obvious.
Effect container components often end up trivial (like a wrap of existing hook) and there is really nothing to test.
There is likely to be a good amount of code reuse, the same "container" is used with a lot of components so there can be a better unit level test reuse for "containers" that need tests.