Not exposing the render() method?

[pathconnected]

Hi, first of all I just wanna say I love the work you are putting on Remix 3.

Coming from the flutter world, I wanted to share this bit of lore. The so called stateful widgets used to have a method called markNeedsBuild, similar to your render method. After early experimentation, they decided to provide a different API to users, one called setState. From the documentation of this method:

The original version of this API was a method called markNeedsBuild, for consistency with RenderObject.markNeedsLayout, RenderObject.markNeedsPaint, et al.

However, early user testing of the Flutter framework revealed that people would call markNeedsBuild() much more often than necessary. Essentially, people used it like a good luck charm, any time they weren't sure if they needed to call it, they would call it, just in case.

Naturally, this led to performance issues in applications.

When the API was changed to take a callback instead, this practice was greatly reduced. One hypothesis is that prompting developers to actually update their state in a callback caused developers to think more carefully about what exactly was being updated, and thus improved their understanding of the appropriate times to call the method.

In practice, the setState method's implementation is trivial: it calls the provided callback synchronously, then calls Element.markNeedsBuild.

Instead of executing code that mutates state and then calling markNeedsBuild, people do

// stuff

setState(() {
  // mutate state synchronously
})

We are also thought and warned by the linter to check if the component is mounted before toying with the context (this) in case of an async gap, i.e. if we await something asynchronous we need to check a property called mounted before touching the context. This is because the component can get disposed before the async call ends. Regarding setState:

It is an error to call this method after the framework calls dispose. You can determine whether it is legal to call this method by checking whether the mounted property is true. That said, it is better practice to cancel whatever work might trigger the setState rather than merely checking for mounted before calling setState, as otherwise CPU cycles will be wasted.

Lastly, in the rare cases where we need to update the component without changing state, as it can (rarely) happen with animations, we are told to do:

setState(() { /* The animation changed. */ });

Not saying you should follow this approach, just wanted to share those decade old thoughts from other people.