@riccardoscalco I looked at your <ternary-plot> source code, and I can't find defition of the data property. Hybrids can only "watch" properties, which are in the definition. If it is an object value, you should add to your index.js component definition the data property:
import { property } from 'hybrids';
export const TernaryPlot = {
...,
data: property({}),
};This also answers the question from @Corvince. The property definition value is a default value. For example, if you want to have property name with "value" as default value, just define it like this:
const MyElement = {
name: "value",
};It uses under the hood translation concept (it translate it to property("value")).
data before the first paint, so data object is available there. Try to not set data - then your component throws an error. Try to secure the case where element is used without passing data. As I wrote before, if you consume a property in the render for most cases it should be in the definition. I think the mistake come from the implicit usage of data property by the nested templates :)
attributeChangedCallback. Take into account that many built-in elements do not update on attribute change, for example, input element. HTML attributes are a better option when you declaratively create UI with static values. Properties on the DOM are a better way to make dynamic changes. It might be possible to use other translation tool from your server, which uses properties instead of attributes (even though the HTML input have attributes).
@smalluban thanks for the quick reply! And sorry I seem to have put my question poorly. What I want to do is to trigger a function with some side effects once a value changes. So for example
const MyCounter = {
count: {
observe: () => doSideEffects()
}Which sure enough works for changes in count, but the initial value of count will be "undefined" and so I can't do something like count += 1. Looking more into this, I think I can create a factory function that includes the default definitions for get (with a defaultvalue) and set. However, is there any way to initialize the value without calling the observe function?
In my use case server has the state and browser only renders it
Custom elements are great fit for complex interaction handling, but I do need them to reflect server state changes. Morphdom is relatively lightweight option for this. Way I see this browser defers to server on this and all interactions get sent to server for evaluation. Thus each change produces new UI state from server rendered html.
Phoenix liveview uses additional change tracking and diffing functionality to get faster, lighter updates. I myself am just experimenting at this point and looked at Hybrids as a way to get functional custom elements from straightforward api. For my particular use case setAttribute is a requirement, but I'll keep it in mind. Especially the property pattern feels powerful tool I can see myself using.
Re: input values. I didn't know this. Interestingly firefox updates input value from setAttribute if element's value property hasn't been changed. If it has, attribute change does not modify property. Not at all what I was expecting. Morphdom seems to special case inputs and sets them through value property probably because of this very reason.
It could be something like this:
import { property } from 'hybrids';
export function propertyWithAttr(defaultValue) {
return property(defaultValue, (host, key) => {
const observer = new MutationObserver(() => { host[key] = host.getAttribute(keyOrSomething); });
observer.observe(host), { attributes: true });
return () => observer.disconnect();
});
}@Corvince I meant something like this:
const MyElement = { count: 0, observedCount: { get: ({ count }) => count, // Now "count" property is a dependency of "observedCount" observe: (host, value, lastValue) => { // do side effect when count changes }, }, };
What would be the advantage of this approach? Compared to using a single property:
const MyElement = {
count: {
get: (host, value = 0) => value,
observe: (host, value, lastValue) => {
// do side effect when count changes
},
},
};count property is translated to property(0), which means it supports attribute fallback and transformation to number. The latter is only a property with value, and in your example is read-only by the way. I suppose that I wasn't your intention. You have to create set manually, if you have get method. Even though you would have set method, it does not transform value to a number, nor uses attribute from html definition. It is fine if you are going to use your element within another built by the library. Built-in template engine uses properties at first, so passing value to nested elements in the template will work.
I think I am slowly getting there. Thanks for taking your time. Finally, would this factory function provide the same thing, but within a single variable?
function observer(defaultValue = 0, func = () => sideEffects()) {
const prop = property(defaultValue)
prop.observe = func
return prop
}Just asking for clarification if there is any more "magic" happening in the translation process. and re: doing side-effects in the set-function: What's the (foreseen) difference between doing them in the set function and the observe function. I am guessing inside "set" it is always called and inside observe only if the value actually changed?
= notation), so it is called even value does not have to change. In your last example, you can use spread operator for simpler structure (the effect is similar):return {
...property(defaultValue),
observe: func,
};I think having connect as an optional argument, but not observe could be kind of confusing. Given this simple code structure, maybe you could even get rid of the connect argument? (Depending on if there will be even more properties)
const MyElement = {
count: {
...property(0),
connect: cfunc,
observe: ofunc,
futureProp: ffunc,
}
}futureProp it will at some point be strange that you can pass a custom connect function (which hypothetical nobody uses), but not the futureProp (which hypothetically everybody wants to use). So just saying that you could depreciate the feature and promote the alternative way in the docs, if that is at all a direction you want to go with hybrids. But there are probably more important things to consider right now ;)
store feature - https://github.com/hybridsjs/hybrids/blob/store/test/spec/store.js. It is now on a separate branch, and not yet finished. Any questions and ideas welcome. In short - it will provide synchronous storage, which is connected to hybrids cache, but it is not a property factory. Still, you can safely use it inside of the property definitions and all will work as it should. It also provides the adapter idea - it allows to observe when the component wants something and in sync or async update the storage with the data. Because of that, the component will not have to worry about imperative call to async API and then render things. What yet left to be implemented is defining "many" relation to other models and how we can detect in "render" that something is being fetched :)
@Yakulu Thanks, I'm fine, quite busy at work, but trying to find some time to finish store feature ;) The cache mechanism is not as complicated as it might look. Every property is wrapped with the cache, so when you get or set property value cache controls what is returned (get) or updated (set). Because every property is controlled by the cache, it can store information about dependencies. If your property getter calls another property (even from another element, but created with the hybirds) it is saved as a dependency of that property. Then, If you observe changes of some property (by observe() method - this is how the render factory works) it is called when one of the dependency changes (by setting value or by calling invalidate, which then return new value). The dependency might be deep, so you can have chain of deps, like this render -> fullName -> firstName - if firstName is updated, the cache will add observe() method of the render property to update queue (using RAF).
To let it work the cache needs to store current and the last value of the property, so in case of memory usage, it has some cost, more significantly if your properties hold a big amount of data. However, the cache uses WeakMapto control references. They are tight to host element, so if you remove it from the DOM (and lose all references) the memory can be cleaned.
Another important fact is how the cache knows that something changed. It is done like other common solutions, eg. useMemo or PureComponent from React. It uses an equality check, so only the reference of the property value is used in the condition. It means that modifying the array will not update the property value. I am not sure what you meant with appending element to the array - but children factory replaces array each time when MutationObserver detects changes in the light DOM of the element - so when is a change in the DOM, the property will be updated with a new list of children.
innerHTML, title or innerHeight that are come from HTMLElement prototype.
host.items = [...host.items, {a: 12}], is every item evaluated into the cache to check if they have changed ?
useEffect() concept, or when to call your external API. In function based mode, the render function is called every time when props have changed. I know that Solid promises to call updates only when needed, and Sinuous has observable() pattern, so you can listen for changes (that is similar concept to observe() method in hybrids descriptor definition).
data: ({ userId }) => getUser(userId),render method (if you use render factory) if one of the render property dependencies have changed. From that point how rendering the DOM is made efficient is related to template engine. If you use built-in template engine from the hybrids, it also caches last values passed to the template. In case of the array, it uses index as default or keys defined by the user (with .key() helper). If you append new element into the array, template engine will reuse all of the values and append new one at the end of the table.