Reduce number of modules

[edkv]

(copied from Slack)

Since you're working on 2.0, I want to share some ideas I have. I was thinking if we can reduce number of modules in the library. For example why do we need Element.Events, Element.Lazy and Element.Region as separate modules? There no name conflicts with the Element namespace, so we can just move everything to the main module and just group stuff under different document sections. I think Element.Keyed can also be avoided - why not just have Element.keyedEl, Element.keyedRow, and Element.keyedColumn? We don't necessary need to mimic elm/html's API.

Finally, I was even thinking if it's possible to have only one module, but I'm not sure about this one. For example I don't see much difference between writing Element.Background.color and Element.backgroundColor, and other name conflicts could maybe be solved by carefully choosing names. The advantage is that we would need to use only one import and it would be possible to do something like import Element as El and have everything under El. But maybe that's too radical :slightly_smiling_face:

[edkv]

Response from @mdgriffith on slack:

I’ve thought about that. If we made that change it would require everyone to make a ton of adjustments to their code for only a very small potential gain. Imagine having 130k lines of code and changing that namespace.

Relatedly though, I’ve been wondering if I should put together a number of elm-ui snippets for VS code (or other editors as well).

The number of import statements could be addressed by having a snippet for when you type

import El<tab>

it expands into

import Element exposing (..)
import Element.Font as Font
import Element.Background as Background
import Element.Events as Events

[edkv]

I’ve thought about that. If we made that change it would require everyone to make a ton of adjustments to their code for only a very small potential gain. Imagine having 130k lines of code and changing that namespace.

It should be possible to make a separate package that provides modules with the old API for compatibility. But yes, that's a problem anyway.

I wouldn't say that it's a small gain though - it's not only about typing less characters, it would (probably) make the library's API much cleaner.

[cdevienne]

Having all background attributes in a Background module (for example) makes it cleaner to me. It makes it easy to look for it in the documentation, and is easy on the eyes when reading code.

[gampleman]

The bigger question is about dropping the Element prefix. elm-ui is a bit of an elephant in the room (pun totally intended) of elm libraries, that if a conflict would occur, it would probably be solved by the other library, so I don't think it would be too much of a problem.

You can check this notebook for what collisions to expect: https://observablehq.com/@gampleman/elm-0-19-conflicting-modules

[cdevienne]

In that case how about renaming Element to UI ? Would be shorter, may even add readability by being more explicit, and match the lib name.

[simvux]

I disagree with renaming to and reserving UI. UI is a very generic name which users are likely to use themselves for types/modules/whatever. However shorting it would indeed be nice. Simply renaming to Elem would work for me

[wolfadex]

I'm for not changing the structure or naming convention. Having separate modules make it very easy to find documentation.

As far as how many characters you have to type, that should be the responsibility of the text editor/IDE and not the library, so I don't see a reason to shorten Element. Like @simvux said about Ui, I use that as my internal naming scheme/wrapper for styled elm-ui elements.