Create a Tips & Techniques section in the docs

[spacejack]

Mithril documentation has been, like the framework itself, concise and to-the-point. This means explaining nuances, best practices or nice ways to do things are often omitted in favour of brevity.

We should probably have a separate page for these sorts of things where we have room to show examples and details that might otherwise distract from the points being made in the core docs. We could also link to sections of this doc from the main documentation as a way to indicate that "there's more to the story than we want to get into here."

[barneycarroll]

Any suggestions to kick us off?

[spacejack]

Couple of things regarding events from the discussion in #2260:

• Re-using event handler functions in closure components
• Using your POJO/class component as an EventListener object

Other things that come to mind:

• Avoiding stale attrs
• Using callbacks or streams to update parent data
• Technique to pass a "querystring" (optional params) in a url
• Ways to force compnent re-init on route change (where the component would otherwise persist)
• Sending a function as children (this is your trick Barney - there's better support in V2 now isn't there?)
• Using children or render functions in attrs
• Example of a canvas component that redraws on attr changes (show an example of implementing your own attrs diff)
• Nuances of using await m.request(). Maybe show an example using promises to defer the redraw until a chain of async operations resolves.
• How to handle error statuses from m.request()
• Explain the difference between running an auto-invoked css animation vs a transition, and why you have to first "force render by reading from the DOM" to trigger the latter in oncreate.

Basically, the most commonly asked things in the Gitter channel. A lot of these are demonstrated in awesome-mithril examples, but within the context of a larger task, so not as easy to find.

[barneycarroll]

This really is a good idea. Too often when we get bogged down in involved use cases we get a kind of fatigue from shifting gears between library documentation and application design patterns. This could nerf that frustration, help fill the void left by the absence of @lhorie's blog — users often pop into Gitter wishing they could get more focused in-depth material on Mithril — and also help assuage my shame at being a non-contributing member of the core team by putting my verbose rants to good use in lasting format.

It might sound silly, but I think this would make most sense as a separate repo (perhaps to be pulled in as part of the site build). This would lessen the pressure of feeling it's somehow something that needs considering in the same head space as iterations on core codebase and the release cycle. Perhaps an official blog is the way to go?

Happy to work on 6 then 4 & 5.

[dead-claudia]

@barneycarroll Agreed on it being a separate repo. We could just have it as a separate sub-site of the main one. Most of what would go here is somewhat subjective.

And most certainly, we should have an official blog here. We'd just want to make it a multi-user blog, so it's clear when something is from us as a unit vs individuals who may have differing viewpoints on various things (like attribute forwarding).

[dead-claudia]

And re: function as children, that got partially shot down in #2050. We came to the conclusion that a view attribute was just as adequate for this use case, and that'd be something really good for a "tips and techniques" site.

[barneycarroll]

Agreed on that last point. James spent a good while arguing the case to me off-channel, but reflecting on React's closure components implementation and its ugly clash of 'native functions are beautifully simple' vs 'how it ties into core logic is mind-boggling' really laid bare what an insidious piece of magic that was. I think that would be a good piece to slot in after an article on animation patterns seeing as that's a far more concrete example of passing functions to compose the lifecycle.

[dead-claudia]

@barneycarroll Found the issue suggesting a blog: #2101. Should that be closed in favor of this, or should we keep both open?

[barneycarroll]

@isiahmeadows closing this, let's go back there.