m.requestrunning 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 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).
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.
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