Giters

elm-community / guidelines

guidelines for *-extra contributors

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proposal: Component curation and collaboration between UI framework authors

rehno-lindeque opened this issue · comments

commented

Forgive me if this has been discussed to death and I'm beating a dead horse. I've been absent from the Elm community for a while and am not sure about the exact state of things anymore, but I'll take the risk.

At my workplace we're currently having a push to start using Elm in internal ui and I'm evaluating which framework we want to use for our controls.

Since I last looked at Elm the number of component packages and UI frameworks have grown impressively. However, the problem now is that there is a bewildering number of packages and different ways of doing things.

The leading framework attempts at the moment seem to be:

In addition there are a bunch of generic and not-so-generic components, including one maintained by elm-community:

These did not exist before and I want to congratulate everyone on the hard work that went into all of these. I'm sure I missed a whole bunch too, sorry.

The growing pain that Elm now faces, in my view, is that there is no basis for comparison between these various approaches. It is also rather difficult to compare Elm with the state of the JavaScript component ecosystem. Some curation and a kind of feature matrix would be immensely helpful for people entering the community. The current situation is very confusing.

Furthermore, while the generic components are very cool it would be pretty nice to have a collection of highly extensible "blessed" components in a single package, elm-community/ui-core. If we had a common set of generic components following an architecture that all of the framework authors could agree upon there would be significant emergent benefits for everyone involved.

Advantages for component authors

  • I feel as though component authors are experimenting somewhat aimlessly at the moment, creating arbitrary components, duplicating work and so on. Some kind of centralized package with a roadmap and feature matrix would give people a path towards getting a particular widget reviewed and potentially "blessed" as a semi-standard component that is likely to be used by other people. They would have to adhere to certain standards, mainly the requirement that it can be extended to work with Bootstrap/Semantic UI/MDL/etc... But, I believe this would have an anchoring effect for people who don't have the time or patience to build a component set themselves but want to contribute something with real value.

Advantages for framework authors

  • A centralized location to document the cross-section of components that are common among frameworks. I would propose taking the largest frameworks and doing an intersection of their components to see what is common. Each author would maintain their own column in this grid:
Component Packages Curated ui-core gdotdesign/elm-ui Bootstrap 4.0 rundis/elm-bootstrap MDL debois/elm-mdl Semantic UI 2.2 gmauricio/elm-semantic-ui Polymer 2.0 edvail/elm-polymer
menu, dropdown elm-menu, SimplyNaOH/elm-searchable-menu ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
menu, context elm-menu, elm-contextmenu

  • Framework authors would not need to rely on the elm-community/ui-core package, they could fork it and then petition to have new components accepted through the PR process. This is similar to how -extra packages currently work. The curation process is slow and arduous, but individual authors can move fast and forge a path forward while still leaving room for consensus to be formed over time. Ultimately some disagreement is inevitable, but in my view the centralization benefits far outway any friction introduced by this.

  • In theory the fastest growing ecosystem is one in which people are individually coding up new components, but in practice people want a curated set of components with consistent conventions, dedicated maintainers, code review, tooling, documentation, forums etc. This is an incredible amount of work for any new framework. Perhaps we can have our cake and eat it too by having a stratified organization where people's attention can be focused appropriately. In this model there would be three categories of contributors:

    • Individuals coding up generic components
    • UI framewok authors extending generic components and creating new generic components
    • UI core contributors curating components from both individual authors and framework authors

  • The ui-core package would serve as a kind of roadmap that framework authors can optionally use to pin their own milestones and priorities. Contributors to these frameworks would also have a clear idea of what is done and what needs to be done.

  • Finally, new framework authors would have the significant benefit of relying on past work. In the ideal case a framework component would simply be the partially applied version of some core component.

For example, at my workplace we'd like to use Semantic UI because we find the aesthetics appealing and mocking up new screens is very productive with the documentation they have available. We will most likely just work with plain elm-html and some basic jquery hacks in order to be productive. However, if such a core component set existed it would make it much easier to contribute back to a elm-semantic-ui package.

Advantages for consumers of UI packages

  • Picking a component framework is very risky at this point. There is no guarantee that it will continue to be maintained and switching to a different one can be extremely costly. I.e. you can't just swap in a bunch of new classes; all of the event handlers, models and configuration is tightly coupled to the framework in question. A core layer of basic components gives you something to fall back to when things go pear shaped. Obviously some frameworks will be more opinionated about the interface they expose than others. People can judge for themselves how much abstraction they're comfortable with.

  • Familiarity with the interface exposed. Similar to the previous point framework authors can choose for themselves how far they want to deviate from the so-called "norms" in a core component set, but at least this establishes some kind of baseline from which to work to try and make your package familiar to users.

  • When a particular framework doesn't expose the component you're looking for you can always revert back to the core component and customize it yourself.

  • As I said before, there is currently no basis for comparison between UI packages. Some of the things users of these packages want to know

    • How complete is the component set
    • What are the caveats with regard to idiomatic Elm. (Is there native code, ports, inline styles, stylesheets)
    • What architectural approach is employed? (Does it expose components? How are config/options supplied etc)
    • Installation method (elm-package, elm-github, gulp, webpack, less stylesheets, etc)

Challenges

Clearly framework authors are going to disagree on certain patterns and I'm not going to try and play this issue down. It's a significant challenge to normalize things in a way that is extensible and satisfies all the stakeholders.

Fortunately Elm is already fairly opinionated about its conventions. From what I understand people have been following Evan's elm-sortable-table example for the most part. I'm not quite sure if it is entirely flexible enough to support all the html patterns that would be needed, but I'd guess that it's close at least.

I'll add to this, let's be mainstream, Elm is already full of compromises intended to normalize things and smooth out the learning curve. Even if framework authors can't agree on everything, they are free to remix to suit their needs.

What do people think about this proposal? Is it is too ambitious, or too early? In particular I'm curious what framework authors think since this plan hinges on their willingness to deal with the overhead of cooperating with a ui-core team (which I'm aware might be a significant PITA and assumes one could form one at all). Currently gdotdesign/elm-ui seems to be the closest thing to a "generic" component library, but it seems somewhat more opinionated still than I'd have in mind.

On a personal note, unfortunately I couldn't tackle a elm-community/ui-core project myself, as valuable as I think it would be. That said, we are working on some specific conventions of our own that I think might be helpful for components but this is a topic I'll leave for another time. There are also probably some things that could be done on elm-package and https://package.elm-lang.org to help in some of these areas but I didn't want to get mired in those details either since it would probably end up going down a rabbit hole.

commented
commented

Nice writeup!

In my opinion there are some things that are needed for standardizing an Elm "component":

  • how to handle hidden state (big discussions about this)
  • API for Element.getBoundingClientRect() this is needed for so many things (dropdowns, drag & drop, etc...)
  • API for input.value = newValue to be able to set values without using input attribute in order to avoid racecondition
  • a way and an API to handle styling of elements, including theming a such
  • a way to test these components, integration style
  • there are probably more which I can't think of right now

To have these in a "blessed" way would probably take a long time (months or years) even if they are on the top of the priorities which I'm assuming they are not. I've spent may hours solving these issues off the grid (check out my repos if you are interested).

I would like to be part of this discussion, If we can put some pressure on people maybe this can happen a little bit sooner.

commented

Here's how I understood this: it would be great if the singular "UI components" had "skins" so that when used with UI frameworks, they fit in with most of them.

I disagree with the sentiment. For me, personally, UI frameworks such as Bootstrap, Foundation etc. have always proven to be a burden sooner or later in the project. What I mean is they might feel super productive in the beginning of the project but later on when the service gains its personality, the predefined look and feel is a huge obstacle to overcome. But there's another side to this, too: I think not a lot of people would embark on a free time unpaid journey to publish e.g. a dropdown package, if it came with the predisposition that they also need to make it comply with five external UI styles. The large amount of code for different skins would also then be part of the package, even if the users want to use custom styles.

I feel that the best "UI component" is one that has the most basic styling needed for nice UX, and a solid way to customize that for whatever style, be it Bootstrap, elm-ui or bespoke design. thebritican/elm-autocomplete worked really nicely for our bespoke design, for example.

You also say

it would be pretty nice to have a collection of highly extensible "blessed" components in a single package, elm-community/ui-core.

I can't help but wonder how this would be useful for many people. I for one much prefer the current state of the world, where I can choose to use Greg's autocomplete and no other pre-made modules. Had it been part of a massive collection package, I probably would have passed it.

I do think that there should be a way to distinguish packages that people have found useful in the package catalogue nowadays. A year ago the whole list of packages was easy to scroll through, but now we have several packages for basically the same thing, and it's quite hard to understand which one is the preferred one by most people.

commented

Thank you @damienklinnert, I tend to prefer the github myself but other folks might be in a slack?

@gdotdesign good comments, thanks! Let me try to address some of your comments inline:

  • how to handle hidden state (big discussions about this)

I know that the "Elm Way" is to not do this, and understandably there's some disagreement. I think state hiding and composition are two discussions worth having in general (we have our own way of dealing with composition at my work, but without state hiding). My hope would be that ui-core could take a neutral stance on this with classical TEA, allowing frameworks decide to hide their models at their own discretion.

In any case, if this is a discussion people want to have at the ui-core level we could start fresh using an issue on an empty ui-core repo and try to come to some kind of consensus there.

  • API for Element.getBoundingClientRect() this is needed for so many things (dropdowns, drag & drop, etc...)
  • API for input.value = newValue to be able to set values without using input attribute in order to avoid racecondition
  • a way and an API to handle styling of elements, including theming a such

My view would be that the core component take some customization similar to Table.Customizations and push styling responsibility down to the framework in question. In other words a ui-core package would be as agnostic as we can manage on these sorts of questions. I think there is some "creativity" involved in many such questions that is perhaps best left to a more opinionated package.

  • a way to test these components, integration style

This is a good point, something I think we could create an issue for this discussion on the package.

commented

Thanks @ohanhi, yes indeed I think this is the crux of the issue (for me):

A year ago the whole list of packages was easy to scroll through, but now we have several packages for basically the same thing, and it's quite hard to understand which one is the preferred one by most people.

The main thing I want as a user of some component is to know whether it follows a couple of basic conventions, e.g. it takes customization that lets me style it however I want, and is flexible enough to allow for most variations I'd commonly want. Also, that it is going to continue being maintained - I don't want to take over ownership of a random component I'm using or wait for 6 months before it is bumped to the next version of Elm.

I suspect the current situation is only going to get more and more confusing as people add lots of components for their own specific use-cases.

Elm-community currently provides code review and maintenance on the -extra packages (on a voluntary basis), which I think they've done an absolutely amazing job with. This is the gist of what I hope could also be achieved for components, although the task may be somewhat more challenging.

commented

I feel that the best "UI component" is one that has the most basic styling needed for nice UX, and a solid way to customize that for whatever style, be it Bootstrap, elm-ui or bespoke design. thebritican/elm-autocomplete worked really nicely for our bespoke design, for example.

I understand your point. I think there are different use cases:

  • as an agency doing work for startups custom styled elements are the way to go
  • as an internal or enterprise tool the looks doesn't really matter as long it's stable and works

What I would like to see and probably implement at some point in Elm-UI is something similar to this: http://empties.bourbon.io which would satisfy most use cases.

commented

@gdotdesign http://empties.bourbon.io/ is just about exactly what I had in mind. I learned something today!

commented

I feel there are so many concerns I could try to respond to here that I'm a bit overwhelmed and don't know where to start. Could someone help me distill the essential questions being asked of me as a "framework" developer of elm-bootstrap ?

My gut reaction/brain dump from skimming this so far is;

  • Too early ? is an ambitious coordination effort perhaps a bit too early ?
    • support for interactive modules and web-platform stuff in Elm is still fairly limited (getBoundingClientRect is just one of many examples)
    • Many are still thinking in terms of components (OO tainted in my head) and no de-facto alternative name for ui stuff that deals with view state in more or less complicated ways has yet been defined
    • People are still trying to figure out the best way to design API's for these things, maybe this needs a bit more time before the best patterns emerge for various use cases ?
    • Maybe it would be more useful to gather experiences and pain points based on real world use cases from package authors and provide coordinated feedback to Evan so that he can schedule a batch for addressing these things in future releases of elm-lang packages
  • Improve the package catalog
    • I feel that improving the package catalog would help people make better/more informed decisions about which route to take
  • Obviously pulling in dependencies always has a cost and a potential risk associated. When considering adding a dependency you should be prepared to make the effort of educating yourself about the compromises involved, what the alternatives are and the history of the author etc etc. Of course it would be cool if there was some objective measure to help people making this work less time consuming/risky. My take on this is
    • elm-lang dependencies: Fine
    • elm-community packages : Mostly fine, but would spend more time considering than above
    • anything else (including elm-bootstrap mind you) : Thoroughly investigate if I can manage without it !

Currently gdotdesign/elm-ui seems to be the closest thing to a "generic" component library, but it seems somewhat more opinionated still than I'd have in mind.

... It's also the only one of the list above I know that isn't in the package catalog. I don't mean to derail the discussion about whether that is ok or not, but it's an important bit of context for people reading this statement.

I'm certainly not making any guarantees about elm-bootstrap, but I'm planning to keep it alive as long as I think it's fun, others find it useful and I have time for it. I'll be happy to try and coordinate with any effort from elm-community and if I for some reason can't keep maintaining elm-bootstrap I'm happy to hand it over to anyone willing to keep it going.

commented

Thanks @rundis, my apologies I did go a little bit overboard on the text.

The TLDR, so to speak, of this discussion is to feel out whether people would be open to a framework neutral package containing unstyled components similar to Evan's elm-sortable-table.

To be clear - I would consider both elm-ui and elm-bootstrap to be framework level packages with their own pros and cons. The hope for a core package would be to serve as a force multiplier for all of the frameworks, letting each focus on their core value proposition rather than worry about implementing sortable tables again from scratch.

People are still trying to figure out the best way to design API's for these things, maybe this needs a bit more time before the best patterns emerge for various use cases ?

I think this is the primary risk here, that things are too early. Perhaps a practical way to go forward would be for a suggestion around some concrete unstyled component to be proposed outlining the conventions used and see how people feel?

An example of something that I thought that elm-bootstrap did a great job with is what it calls State, Options, and Config. I'd generally like to see that convention propagate to other components, but as you say - maybe that would involve too much contention. There's a risk here of stifling innovation as well if people end up feeling that this is the only way of doing things.

I should add, please don't take me as a representative of elm-community. I happen to be a (embarrassingly inactive) member here but others would have to chime in about whether they'd be willing to host a project like this here.

commented

I totally understand the frustration of having many things to choose from and finding it difficult to pick something.

But I wouldn't like the elm-community organisation endorsing a particular way to structure ui libraries. I still see many conventions and patterns still unclear. And I like new people bringing new ideas on how things can be done. I think is very risky to push forward a particular way. For example I don't think that sortable-tables is a particular good example to follow.

I think that if a particular group of devs wants to make their own component framework, then that is great, they can come up with conventions and patterns and others might choose to follow them. But I don't think that the elm-community should get very involved with this for now (as in endorsing or curating).

Maybe a good trade-off could be a repo documenting some known patterns for UI libraries, listing pros and cons for each.

commented

Thanks @sporto, ok I get the impression that the overall feeling is that getting traction with a neutral package might be a bit much to ask for the moment.

Maybe a good trade-off could be a repo documenting some known patterns for UI libraries, listing pros and cons for each.

As a fallback I think a component matrix would be a very good idea. If I get some time I'll try to help out.

I might slowly play around with a ui-basics in a personal repo for a bit as well (where the term "basics" is intended to be much less strong than "core") and see where that goes, though I'm afraid I'm probably not in a position in life to maintain such a thing. A bit of experimentation can't hurt though.

Thank you everyone for hearing me out, I was impressed at the level of responsiveness from folks interested in the topic.