Mithril.js Bucket List

[dead-claudia]

Do subscribe to this to keep updated! I do try to keep this up to date!

This is a meta bug for some of the more prominent proposals that haven't been rejected. Discussion on any of these ideas specifically are better left on the relevant sub-bug of this one. Being on this list does not guarantee it'll be in the next version of Mithril.

If I missed anything, a new bug was opened for something on this list, or if something else comes up, please tell me. Just make sure to @mention me so I'll know about it and can update this accordingly.

• a. Modularize the source code somehow. Make Mithril modular #651, Making Mithril modular #665 (PR itself dead)

• b. Use classes as components (ES6, TypeScript, CoffeeScript, etc.). Components don't work with ES6 classes. #618

• c. m.deferred()/m.sync() → new Promise()/Promise.all(). Depend on ES6-style promises instead of using Mithril deferreds #800

  This will add a single dependency for a compliant ES6 or Promises/A+ Promise implementation, only for m.request and m.prop(thenable). The old forms will be deprecated, and this will be a breaking change.

• d. m.prop() should be a little less infectious. #800 (comment)

• e. Lint the source, likely with ESLint. Linters, anyone? #706 (Merged in Convert tests to Mocha/Chai/Sinon and lint them. #822, Lint Mithril main #828, Make linter happy with mithril.js #973)

• f. Use a real testing framework for all the tests & unify with QUnit tests. Use a real testing and assertion framework #801 (Merged in Convert tests to Mocha/Chai/Sinon and lint them. #822)

• g. Partial rendering. Partial rerendering proof of concept #291, related to Smarter redrawing: diff a tree of values rather than a tree of virtual DOM #538

• h. Iterables as template arguments. Support for generators #517

Some of these were mostly discussed in the Gitter room, while others originated in other bugs.

/cc @lhorie (You're welcome in advance.)

[dead-claudia]

I also know this is probably not the best of titles, so if you have something better, please share. I'll probably take it.

[lhorie]

@IMPinball A few other ones off the top of my head:

• partial rendering
• class sugar (e.g. {class: {foo: shouldFooAppear}} )
• generator support
• HTML namespace support

[tinchoz49]

hi guys! @lhorie i think the class sugar can be defined as an external module or maybe better simple use classnames

{
  class: classnames({
     foo: shouldFooAppear
  })
}

[dead-claudia]

As soon as I get to a computer, I'll update.

On Mon, Sep 28, 2015, 12:35 André D [email protected] wrote:

For example, say I have a library which sorts, filters, paginates tables
etc (like datatables). I can use a mithriljs component to render out that
table beautifully and then use config to pass that table off to the
library. However, from that point on if I want to re-render that table I
have to re-render the entire page (say for example, I have a mithril-driven
dropdown to change which animal specifies I am looking at as a whole, and
this table is a small widget within the page as a whole, or I have multiple
of them on the page, etc).

—
Reply to this email directly or view it on GitHub
#802 (comment).

[dead-claudia]

Updated!

[dead-claudia]

Updated! (recent patch)

[dead-claudia]

Updated! (recent patch & Gitter discussion)

[barneycarroll]

• generator support

@lhorie generators are a language feature, the onus on support is in the runtime environment. Where do you see these being involved in Mithril?

[lhorie]

@barneycarroll someone had mentioned that it would be nice to support them in templates, e.g.

m("ul", liGenerator) //render a bunch of <li>'s

It's more of a nice-to-have than anything else, and not a huge priority

[dead-claudia]

@lhorie would you be okay with later making components be able to return
arrays?

On Mon, Nov 9, 2015, 12:50 Leo Horie [email protected] wrote:

@barneycarroll https://github.com/barneycarroll someone had mentioned
that it would be nice to support them in templates, e.g.

m("ul", liGenerator) //render a bunch of

's

It's more of a nice-to-have than anything else, and not a huge priority

—
Reply to this email directly or view it on GitHub
Mithril.js Bucket List #802 (comment).

[lhorie]

@IMPinball yeah I'd like to make that work at some point

[dead-claudia]

Removing "CSS class object (string-boolean hash maps)", as they appear to be losing support there in favor of classnames.

[tinchoz49]

@IMPinball i agree!

[dead-claudia]

Updated

[dead-claudia]

Updated!

[dead-claudia]

Updated!

[lhorie]

linting and m.prop promise infectiousness were reverted in 0.2.2-rc.1, so I'm unchecking those items

[dead-claudia]

I'm fine with that.

On Sun, Dec 20, 2015, 19:39 Leo Horie [email protected] wrote:

linting and m.prop promise infectiousness were reverted in 0.2.2-rc.1, so
I'm unchecking those items

—
Reply to this email directly or view it on GitHub
#802 (comment).

[lhorie]

Going to close this in favor of #1090