Can Web Components pretty much do everything without a framework now? I think Ionic moved to it for example. If we already have our own code for loading and rendering components, using Handlebars templates, what would we need to do to make them into web components instead, or make all of ours compatible with the latest React or Angular?
The specifics for anyone who cares:
When we began our own framework, way before React and Angular, we built our own, kinda “sane” reusable component engine. We called them “tools”. One tool on an element is a component. But you could also add multiple tools on a component, to add or remove behaviors:
Basically, we figured it would be easier to just let Templates, HTML, CSS and JS each do what they were intended for.
HTML side
1. We had <div class=“Q_Tool Streams_chat_tool” data-streams-chat=‘{“foo”: bar, ...}’> easily exporting json from php or templating engines, very readable and completely standard (no JSX or custom components). It was just slightly longer to write but provided useful metadata. It used to be called microformats back in the day. Multiple tools can be added on same element this way. The element didnt have to be a div.
2. We had handlebars helpers like {{&tool “Streams/chat” foo=bar}} and Q.Tool.setUpElement(“div”, toolName, options), or pass an element instead of “div” to add a tool on an existing element. We also had a jQuery fn method like $(“foo”).tool(“Streams/chat”, options).activate() .
3. Our users just called var element = Q.activate(Q.Tool.setUpElement(“div”))) in vanilla JS or $(“<div />”).tool(...).activate() if jQuery was loaded.
* CSS side*
1. We namespaced our CSS by Modulename_toolname_
2, Some tools took advantage of shared CSS classes defined in the module or a module they depend on
Javascript side
1. We just had Q.Tool.define(toolName, constructor, defaultOptions, methods) and the tool.state would be the options merged over the defaultOptions. It was all customizable and merging was done via a smart Q.extend() function that we tweaked to eg combine Q.Event handlers in the best way.
2. Ways to access tools on an element would include Q.Tool.byId() and element.Q.tools etc. The tool ids would be autogenerated so as to establish a hierarchy of which tool was a parent. Then you could do tools.children([filterName]) and tools.parents() and so on. Traverse faster without touching the DOM.
3. We had Q.activate(container, options) to activate tools within a certain container. Javascript for tools would be loaded on demand, and tools would be added/removed on demand. We had Q.Event.prototype.add(callback, key) take a String key or a Q.Tool, so events would be automatically removed when a tool was removed.
4. You could also do Q.Tool.define([toolName1, toolName2], toolName, constructor, defaultOptions, methods) to have tools require that previously named tools already be activated on the element. This is for composability of tools, something more general than inheritance. Let’s say you have a chatroom and you want to add support for @mentions to it and https://linkscraping.com as you type. So you’d make tools that work in top of Streams/chat.
It seems to me that ANYWAY your user will have to load a Javascript file that defined your web components. And ANYWAY they will have to load javascript on demand. And ANYWAY this javascript may be packed into a single file so you’ll have to actually check whether a variable has been set before loading modules dynamically so you dont want static loading. And ANYWAY your tools may want to use shared css so you may as well namespace your CSS. And ANYWAY your default options may include event handlers or other things you can’t serialize easily into attributes of an element. And you may want to compose tools or find them with CSS so what’s wrong with using CSS classes instead of the element name for that? And ANYWAY you will want to render your tools in a readable way so why not stuff JSON into data attributes which were allowed for exactly such purposes? And ANYWAY you may want to use a powerful templating engine like Handlebars. The only part I am not sure of is the last one.
Seems to me - but I am biased - that we have the optimal approach. If something else comes out we can just turn Q.Tool.define into a wrapper around window.customComponents.define. But our users won’t have to change a thing. They can continue to use Q.Tool and Q.Page and Q.exports(arg, arg) and Q.requires(module, callback) without worrying what’s underneath. Isn’t it better and more stable?
But everyone got into Angular and React with its JSX etc. I think the main sell was the dirty checking (the model in Angular, the DOM in React). So you can just render a large chunk. I never saw the benefit of that. You should reason about mutations imho. Components are views with their own viewmodel, that’s all. You can update a bunch of state parameters and then call stateChanged(“a”, “b”) which would requestAnimationFrame() and update stuff. Is it so hard to call stateChanged() after changing state.a and state.b ? Do you really need to instead grok digest cycles or a virtual dom??
https://blog.usejournal.com/web-components-will-replace-your...
Can Web Components pretty much do everything without a framework now? I think Ionic moved to it for example. If we already have our own code for loading and rendering components, using Handlebars templates, what would we need to do to make them into web components instead, or make all of ours compatible with the latest React or Angular?
The specifics for anyone who cares:
When we began our own framework, way before React and Angular, we built our own, kinda “sane” reusable component engine. We called them “tools”. One tool on an element is a component. But you could also add multiple tools on a component, to add or remove behaviors:
https://qbix.com/platform/guide/tools
Basically, we figured it would be easier to just let Templates, HTML, CSS and JS each do what they were intended for.
HTML side
1. We had <div class=“Q_Tool Streams_chat_tool” data-streams-chat=‘{“foo”: bar, ...}’> easily exporting json from php or templating engines, very readable and completely standard (no JSX or custom components). It was just slightly longer to write but provided useful metadata. It used to be called microformats back in the day. Multiple tools can be added on same element this way. The element didnt have to be a div.
2. We had handlebars helpers like {{&tool “Streams/chat” foo=bar}} and Q.Tool.setUpElement(“div”, toolName, options), or pass an element instead of “div” to add a tool on an existing element. We also had a jQuery fn method like $(“foo”).tool(“Streams/chat”, options).activate() .
3. Our users just called var element = Q.activate(Q.Tool.setUpElement(“div”))) in vanilla JS or $(“<div />”).tool(...).activate() if jQuery was loaded.
* CSS side*
1. We namespaced our CSS by Modulename_toolname_
2, Some tools took advantage of shared CSS classes defined in the module or a module they depend on
Javascript side
1. We just had Q.Tool.define(toolName, constructor, defaultOptions, methods) and the tool.state would be the options merged over the defaultOptions. It was all customizable and merging was done via a smart Q.extend() function that we tweaked to eg combine Q.Event handlers in the best way.
2. Ways to access tools on an element would include Q.Tool.byId() and element.Q.tools etc. The tool ids would be autogenerated so as to establish a hierarchy of which tool was a parent. Then you could do tools.children([filterName]) and tools.parents() and so on. Traverse faster without touching the DOM.
3. We had Q.activate(container, options) to activate tools within a certain container. Javascript for tools would be loaded on demand, and tools would be added/removed on demand. We had Q.Event.prototype.add(callback, key) take a String key or a Q.Tool, so events would be automatically removed when a tool was removed.
4. You could also do Q.Tool.define([toolName1, toolName2], toolName, constructor, defaultOptions, methods) to have tools require that previously named tools already be activated on the element. This is for composability of tools, something more general than inheritance. Let’s say you have a chatroom and you want to add support for @mentions to it and https://linkscraping.com as you type. So you’d make tools that work in top of Streams/chat.
It seems to me that ANYWAY your user will have to load a Javascript file that defined your web components. And ANYWAY they will have to load javascript on demand. And ANYWAY this javascript may be packed into a single file so you’ll have to actually check whether a variable has been set before loading modules dynamically so you dont want static loading. And ANYWAY your tools may want to use shared css so you may as well namespace your CSS. And ANYWAY your default options may include event handlers or other things you can’t serialize easily into attributes of an element. And you may want to compose tools or find them with CSS so what’s wrong with using CSS classes instead of the element name for that? And ANYWAY you will want to render your tools in a readable way so why not stuff JSON into data attributes which were allowed for exactly such purposes? And ANYWAY you may want to use a powerful templating engine like Handlebars. The only part I am not sure of is the last one.
Seems to me - but I am biased - that we have the optimal approach. If something else comes out we can just turn Q.Tool.define into a wrapper around window.customComponents.define. But our users won’t have to change a thing. They can continue to use Q.Tool and Q.Page and Q.exports(arg, arg) and Q.requires(module, callback) without worrying what’s underneath. Isn’t it better and more stable?
But everyone got into Angular and React with its JSX etc. I think the main sell was the dirty checking (the model in Angular, the DOM in React). So you can just render a large chunk. I never saw the benefit of that. You should reason about mutations imho. Components are views with their own viewmodel, that’s all. You can update a bunch of state parameters and then call stateChanged(“a”, “b”) which would requestAnimationFrame() and update stuff. Is it so hard to call stateChanged() after changing state.a and state.b ? Do you really need to instead grok digest cycles or a virtual dom??