m.request
running server and client side, so no need for a store facade, thanks @dontwork for the inspiration
Howdy @StephanHoyer! Apologies for the text dump, but I figured I'd reach out on gitter before opening a bunch of issues on github.
I have some free time this weekend, and I'd like to help out with mithril-node-render
(and work towards some hacktoberfest swag :sweat_smile:).
If you're interested in any of the following ideas, I'll open some issues for more discussion, then I can work on some PRs:
Make the new isClass
function match how Mithril itself checks for class components: i.e. classes don't have to actually use class
syntax, they just need to be functions that have a view
method on their prototype. This would simplify the check, and prevent possible incompatibilities between mithril
and mithril-node-render
.
Move mithril
to a peerDependency
: This is how react-dom
and React Native handle their depedency on React, and would help prevent issues like #58 in the future. I imagine most users consuming this module probably already have mithril
installed as a dependency, so you wouldn't run into the peerDependency hell that you do with e.g. eslint plugins and presets.
Update documentation a bit: There's a few minor grammar hiccups, and a couple areas that I think could use a bit more clarification (e.g. escaping).
Switch from co
to async
/await
: this would be a breaking change and would only work on node >=8, but it would remove the dependency on co
and I think make the code slightly more idiomatic.
Implement #65: I feel like this would be a pretty big change, but I could take a stab at implementing it as e.g. renderSync
. With async
/await
becoming more mainstream, though, I don't know how relevant this still is?
5.
I thought about a simple vdom2html converter that doesn't have component support, that might be enought for the mentioned usecase