maildev@lists.thunderbird.net

Thunderbird email developers

View all threads

custom elements, models, and views

PM
Paul Morris
Fri, Oct 11, 2019 5:54 PM

Hi all,

I wanted to share some thoughts on custom elements (CEs) and how they
relate to UI patterns that separate model from view -- various themes
and variations on MVC (model, view, controller):

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Basically, CEs don't encourage separation of model and view (data/state
and presentation).  One of the main things they offer over plan HTML is
letting you couple JS logic with a particular piece of HTML/CSS UI.  One
of their main use cases was to bundle all of that up into self-contained
units that could be dropped wherever but not de-composed.  (I.e. put a
google maps widget on your website.)  In short, they enable and tend to
encourage keeping state in DOM nodes/local component state, which
couples the model and view together.

Separating model and view is a pretty well established UI approach with
various benefits.  MVC dates from the 1970s, and more recently in the
web dev world we had a broad shift away from jQuery to React/Redux etc.

While CEs make a lot of sense as an upgrade/migration path away from
XBL, I think it's worth considering as we go forward, whether we should
move towards greater separation between model and view in our UI code. 
I think there's a lot of unnecessary complexity and brittleness in our
UI code that could be improved by this kind of separation of concerns. 
Here are a couple of articles on this topic:

UI as an afterthought
Makes the general case really well.
https://medium.com/@mweststrate/ui-as-an-afterthought-26e5d2bb24d6

Choosing a web component Model
A short post I found that makes the comparison between web components
and MVC, etc.
https://medium.com/@daveford/choosing-a-web-component-model-f83bb9a8edae

Consider an example.  Just for sake of argument, say we wanted to offer
two UIs for entering recipients for a message, a plain text one and a
pill-based one, and we wanted to be able to toggle between them on the
fly.  Or maybe an addon wants to offer an alternative UI.

If we have the model separate from the view, then it is just a matter of
switching the view.  If we have our model coupled with one particular
view, then it is not so simple.

Consider addons that want to modify the UI (like "Conversations" or
"CardBook").  It would be much more feasible to see how that could work
if we had more separation between model and view.  It's easier to
imagine where WebExtensions APIs might hook in, in a world with greater
model/view separation.

Or consider making TB more scriptable via command line, etc.

These are just some preliminary thoughts I've had about this as I've
been working with CEs, and now as we move past de-XBL to moving the UI
forward.  Curious to hear what others think.

-Paul

Hi all, I wanted to share some thoughts on custom elements (CEs) and how they relate to UI patterns that separate model from view -- various themes and variations on MVC (model, view, controller): https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Basically, CEs don't encourage separation of model and view (data/state and presentation).  One of the main things they offer over plan HTML is letting you couple JS logic with a particular piece of HTML/CSS UI.  One of their main use cases was to bundle all of that up into self-contained units that could be dropped wherever but not de-composed.  (I.e. put a google maps widget on your website.)  In short, they enable and tend to encourage keeping state in DOM nodes/local component state, which couples the model and view together. Separating model and view is a pretty well established UI approach with various benefits.  MVC dates from the 1970s, and more recently in the web dev world we had a broad shift away from jQuery to React/Redux etc. While CEs make a lot of sense as an upgrade/migration path away from XBL, I think it's worth considering as we go forward, whether we should move towards greater separation between model and view in our UI code.  I think there's a lot of unnecessary complexity and brittleness in our UI code that could be improved by this kind of separation of concerns.  Here are a couple of articles on this topic: UI as an afterthought Makes the general case really well. https://medium.com/@mweststrate/ui-as-an-afterthought-26e5d2bb24d6 Choosing a web component Model A short post I found that makes the comparison between web components and MVC, etc. https://medium.com/@daveford/choosing-a-web-component-model-f83bb9a8edae Consider an example.  Just for sake of argument, say we wanted to offer two UIs for entering recipients for a message, a plain text one and a pill-based one, and we wanted to be able to toggle between them on the fly.  Or maybe an addon wants to offer an alternative UI. If we have the model separate from the view, then it is just a matter of switching the view.  If we have our model coupled with one particular view, then it is not so simple. Consider addons that want to modify the UI (like "Conversations" or "CardBook").  It would be much more feasible to see how that could work if we had more separation between model and view.  It's easier to imagine where WebExtensions APIs might hook in, in a world with greater model/view separation. Or consider making TB more scriptable via command line, etc. These are just some preliminary thoughts I've had about this as I've been working with CEs, and now as we move past de-XBL to moving the UI forward.  Curious to hear what others think. -Paul