million: [RFC] Educating developers on the `block` pattern
Currently, our project is positioned where the actual block
function and For
component work well enough in the cases it does work. But when it doesn’t work, shit hits the fan… really quick. This is the biggest barrier for adoption for our project.
Example of shit hitting the fan:
This is a threefold problem:
- We do not have great error messages.
We need to invest a lot more time in invest into error messages. <For />
example, we do not support non-deterministic / early returns. We should have both an error message in the client and server for this problem. It should not only show an error, but identify the exact line of the problem, and furthermore, give reasoning and documentation for the error.
Right now, it either is just a “rule of hooks is broken” error or a document is not defined
error, both of which are non-descriptive and very unhelpful.
We should also suggest how to restructure components. Blocks are not always a clean function wrap, they require restructuring of components in order to work properly. Furthermore, we can remind developers to use the <For />
component when .map
is used on a block.
- We have not defined the proper use cases of
block()
We still do not know where block should be used. We need to define rigid use cases where block is actually helpful. General guidelines like “more static than dynamic” is not really helpful to most React developers.
This specific point can also help us with the 1st problem mentioned. By defining the proper use cases, we can remind developers when not and when to use blocks.
- We do not educate developers on how to use the “magic” of block
Our docs are lacking a lot of content for new developers to understand and use. This goes along with 2 and 3.
For any efforts happening right now around Million.js, they will be paused for fixing this critical issue first.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 2
- Comments: 15 (15 by maintainers)
We need to establish a “best practices list” for million. We can also implement an eslint plugin to help developers identify the common issues.
@SukkaW Yeah, the reason I removed forgetti in the first place was because it didn’t make sense in the context of the project. But if it can help us fix invalid hook calls, then it is a HUGE bonus for the project
#344