Comment by dmitriid
4 years ago
Separation only works for so-called leaf components: buttons, links, tabs etc. that can actually be reused.
And even then you will definitely run into issues such as "in this particular case this particular tab will look like this".
While the web was mostly leaf components (text, articles, images, links) this separation kinda worked. The moment you move into app territory, there are not that many things that are reusable and benefit from separation, because your UI is directly dependent on business logic and vice versa. And because every screen in your app is a unique view into a unique part of your functionality.
Very true. Even in "leaf" components (I'd never heard them called that. Cool.), the actual appearance is often dependent on some state that only the parent knows. Is the button highlighted or dimmed? Blue or red? Well, the button component doesn't know. (It shouldn't). But the parent who spawned it must know and pass that information into the button by a param.
This should, ideally, be as short and sweet as possible. In reality, like you say, the two ideas (visual + biz logic) will always be married in any non-trival application.
leaf components as a term appears in various discussions on web components. Many people don't see the value in full-blown web components(as they have lots and lots of unsolved issues), but agree that they may fill the niche/need for "dumb" reusable components at the end of the DOM tree (hence, leaf :) ): date pickers, buttons, links, all that kind of stuff.
I've seen tons of libraries of these and every big company seems to make their own, then try to release it to "help others." It's a noble idea, but the reality is that most of the cruft in those component sets won't be useful to app developers who aren't making apps for that company.
In other words, you are likely to need too many customizations even to leaf components to be able to use someone else's.