3 ms·

I use web components, but I often want to design classes as MVC. It isn't obvious how this should work (though I assume the Web Component spec authors discussed

I use web components, but I often want to design classes as MVC. It isn't obvious how this should work (though I assume the Web Component spec authors discussed the topic at some point). The awkwardness is: (a) When you instantiate your View class (ie: 'web component') from JS, you probably want your Model and View to be 'owned' by properties of the Controller (eg: con.model and con.view). However... (b) when an HTML tag instantiates your View, the View has to create its Model and Controller. And now there's no obvious place to store a reference to the Controller. As a result, you have either to stick the Controller in a global variable somewhere, or - more likely - end up, not just with 'con.model' and 'con.view', but also with a new property: 'view.con' So... two paths to create everything (Controller-based, or View-based), and this ugly '.con' property stuck in the View. But, aside from this gripe, Web Components are okay.

mattlondon 2y ago
I don't think we components were intended as a complete "framework" for writing web apps, but more for the rendering of reusable UI components. So trying to do MVC with just web components feels a bit weird, at least to me. You'd need something extra I think
- thomassmith65 2y ago
  The problem is that the ShadowDOM is sort of the real View, and the CustomElement (judging it by its methods), is kind of a mix of a View and a Controller. Perhaps I should try making my controllers the HTMLElement subclasses, instead of my views. My gripe remains: the best approach is not obvious.
  - thomassmith65 2y ago
    Note to whoever comes across this comment in future. So I have now explored using HTMLElement as the Controller, its shallow DOM as a data source for its Model class, and its ShadowRoot as a subclass. It is clear to me now that that design would be the most natural fit for MVC. However... it is also impossible. For whatever infuriating reason, they designed custom element's ShadowDOM class to not be subclass-able. You can neither give a ShadowDOM subclass a constructor, nor does HTMLElement reveal any mechanism to 'attach' a ShadowDOM subclass. Fantastic /s

mattlondon 2y ago

I don't think we components were intended as a complete "framework" for writing web apps, but more for the rendering of reusable UI components. So trying to do MVC with just web components feels a bit weird, at least to me. You'd need something extra I think

thomassmith65 2y ago
The problem is that the ShadowDOM is sort of the real View, and the CustomElement (judging it by its methods), is kind of a mix of a View and a Controller. Perhaps I should try making my controllers the HTMLElement subclasses, instead of my views. My gripe remains: the best approach is not obvious.
- thomassmith65 2y ago
  Note to whoever comes across this comment in future. So I have now explored using HTMLElement as the Controller, its shallow DOM as a data source for its Model class, and its ShadowRoot as a subclass. It is clear to me now that that design would be the most natural fit for MVC. However... it is also impossible. For whatever infuriating reason, they designed custom element's ShadowDOM class to not be subclass-able. You can neither give a ShadowDOM subclass a constructor, nor does HTMLElement reveal any mechanism to 'attach' a ShadowDOM subclass. Fantastic /s