Mithril should emit a warning if an array of children have non-unique keys

[balupton]

I did my first Mithril app earlier this week, and spent 3 hours debugging why I was getting super bizarre behaviour. It turned out that I had Data.items.list.find(i => i.id = id) instead of Data.items.list.find(i => i.id == id), which was then later rendered like so:

		return m('.block', Data.items.list.map(
			(item) => m(SomeComponent, {key: item.id})
		))

It would be really nice if Mithril emitted a warning if the children array contains non-unique key values. If such a thing existed, it would been reduced from 3 hours of debugging to a few minutes.

[pygy]

Adding a check for this isn't hard, but it would add overhead in probably the most perf-sensitive function of the render engine. We may or may not add it depending on how much it affects perf...

[leeoniya]

this is a devmode-only thing (if mithril has one). in production builds this would destroy performance.

[barneycarroll]

Might be worth adding this to the bucket list of "if Mithril did warnings". For a while we've been talking about "gotchas" as distinct from the "anti-patterns" detailed in the documentation. In the distant future, when other meta-repo issues have been addressed, a policy of liberal warnings in source, along with a build step that stripped out the code paths, would be a nice idea.

[dead-claudia]

@leeoniya

this is a devmode-only thing (if mithril has one)

We don't, although I've recommended it multiple times in the past in various channels.

[tivac]

Stripping code from builds isn't difficult, though with mithril's custom bundler everything is a bit trickier than it should be. 😅

[orbitbot]

Devmode publishing seems like a thing that should be done right, if at all. Since the point would be to keep the warnings only in development, that means that consumers should essentially need to be able to selectively strip out the code themselves, or then switch source files in their build automatically. There's probably some established patterns for this, my main point is that module consumers need to be able to include both devmode and prodmode in their tools, and ideally getting there without being forced to put more tools in their build config. So end result being that there basically should be four different source sets to consume, unless I'm missing something.

[balupton]

Perhaps the minified version (can be the require('mithril') version) can be the production build.

With the unminified version (can be a require('mithril/dev') version) can be the development build.

This would solve the user having to do any custom build setups.