Control.float about elm-debug-controls

[avh4]

Yeah, I'd be happy to accept a PR for this 👍

[ianmackenzie]

Cool! I do remember running into some "huh..." moments when I wrote my custom implementation of Control.float for my own use case - I vaguely seem to remember concluding that it was inherently different from some of the other controls, in ways that made it non-obvious how to match existing patterns.

I'll try to take another look at the code again and see if I can refresh my mind on what these issues were - are there any particular principles you've been trying to follow with the existing controls, or gotchas to be aware of to make sure that layout works out in a reasonable way in all cases?

[avh4]

I haven't worked on this in quite a while, but just to dump out the context I recall:

• the current way things are done is a bad practice in Elm because it is storing a bunch of functions in the model, and it's also bad practice in that the msg the views produce is basically a new model value rather than an actual message. But for the moment, I've decided to stick with both those bad practices given this is a package for "debug"ing, and it reduce the boilerplate needed to use it.
• the layout of the views is definitely not well thought out. so atm, whatever gets added is fine, I think, so long as the packaged examples still work okay.

in a future major version, both those things are up for reconsideration, but in the meantime, I've just been living with the current mess, and trying to keep notes of the cases that don't work right to inform the later potential redesign.