Patrik Johnson
Patrik Johnson
Details, but AFAIK you can also just check for the existence of `window.console` before logging to avoid that much more complex code.
@barneycarroll identified it in the chat that it's an issue of having multiple separate mithril instances loaded in the same page. This should probably be fixable by tweaking the webpack...
@space88man 🎖 Noticed the following: - I don't believe it's particularly meaningful to use an IIFE for the main component [here](https://github.com/space88man/todomvc-mithril2/blob/master/js/views/main-view.js#L24) - the call to `Data.init()` [here](https://github.com/space88man/todomvc-mithril2/blob/master/js/views/main-view.js#L29) might as well...
> On the other hand, @StephanHoyer's example makes me wonder, does mithril need to handle state at all? Could it only worry about component identity and handoff state approaches to...
> // Property updated by the renderer before each update // Gets awkward in a hurry, but if we shorten it to `i.attrs.class`, it might be // workable. Code examples...
> > Code examples can use destructuring syntax by now > > You have to be careful where you destructure: > > ```js > // Good > function Foo(ctx) {...
Chewing on the latest a bit, I don't really understand the value proposition of `i.state` and `i.link`, as it kind of mainly seems like a larger surface API to achieve...
IMO the original proposal works for most stuff, but `m.request` is just messy no matter what if everything is explained at once. Might be easier to read with the MDN...
To be clear, my issue with the documentation in the case of something like the amount of options that `m.request` has is that it isn't readable, not that there are...
+1, any chance of a merge?