As for me, it is encapsulation of behavior, which primarily involves data handling and lifecycle management. I see everything else as additional options.

It depends on the specific implementation. You can enforce the use of methods that trigger an event by default, and you can also use structuredClone to ensure the immutability of the received data. However, it is generally better to use the received data for reading only, and pass it by reference.

An Example of Data Exchange Between Web Components In the previous articles, I devoted significant attention to the theoretical aspects related to...

So, after all the theoretical blah-blah, here’s a practical example showing how Web Components can exchange data in a native, simple, and highly flexible way.

dev.to/valkoivo/an-...

#WebComponents #JavaScript

Handshake Between Web Components In the previous article, we made an important assumption: if the environment initializing a web...

So, we have reached the point where our two Web Components perform a handshake to initiate communication.

In this article, I’ve made some bold statements. I’d love to hear your criticism.

dev.to/valkoivo/han...

#webcomponents

I thought about an alternative approach—passing the service identifier as an attribute to the component, which can be easily changed. This way, the component would rely not on a specific service, but only on the data format and exchange protocol.

How would you recommend implementing the following scenario? Suppose I have two data sources, such as two servers with different APIs, but the data is in the same format. I'd like the component to show data from either server based on the user's choice.

Suppose we have two services on the page, and a component is connected to one of them. How can we instruct the component to switch to the other service?

Interesting thought, but I'd like to ask, how can a component be made to switch from one service to another at runtime?

I try to use underscores. This is usually sufficient. Should the property be totally hidden? Imagine you urgently need to test a hypothesis, and for that, you want to access a private property just once. It won’t go to production, you just need to check. The underscore allows you to do that.

KoiCom Data Management with KoiProvider and KoiTransmitter This article explains the KoiProvider component, a data storage tool in the KoiCom library. It manages data, triggers change events, and connects with other components. It also covers avoiding feedbac...

Thank you for your feedback. Please review the basis I use for such data providers. When a provider retrieves data from the server, it stores the data in its own data object and notifies its consumers.
valkoivo.github.io/koicom/docs/...

Methods for Initializing Web Components with External Data In the previous article, we discussed the criteria that the environment initializing a web component...

This time, let's talk about different ways to insert data into #WebComponents during initialization and try to choose the one, the only one, that rules them all.

dev.to/valkoivo/met...

#javascript #frontend

It seems that the biggest debate about var, let, and const ends here

github.com/microsoft/TypeScript/issues/52924

github.com/microsoft/TypeScript/pull/52832

issues.chromium.org/issues/42203665

Thanks, Demi Murych
#JavaScript

Initialization of a Web Component with External Data In the previous article, we discussed why data encapsulation is a key characteristic of a...

Let’s continue disrupting the calm and pointing out the hidden details of seemingly obvious things.

#webcomponents

dev.to/valkoivo/ini...

For example, from the component's attributes. This way, you won't need an import at all, and the component's usability will improve immediately. For instance, you could connect the component to any desired signal simply by changing an attribute's value in the HTML.

In the end, you'll need to do much more to make the component portable without having to worry about its environment. But there's a simpler way to approach this from the beginning. You only need to ensure that the signal reference is obtained not from global variable.

However, you just demonstrated that to make things more convenient for other developers, certain rules need to be followed. But the current code won't be the end of it. Next time, I'll point out that the 'count' name could conflict with another name, which would prompt you to introduce namespaces.

I understand your reasoning. Moreover I think that JavaScript is an excellent language precisely because it allows for a lot that compilers in other languages would strongly object to. I have nothing against signals.

Exactly. When using signals, you should pass a reference to the signal through component attributes, method parameters, or another clear mechanism. Otherwise, it’s confusing to see a method call in the class code that isn’t defined within the class itself.

I mean that the issue with global variables isn’t just that they can be modified anywhere in the code—it’s also that, when reading a class’s code, you might come across a variable without knowing its origin.

I don’t mind subscribing and unsubscribing, but a class should know about external objects explicitly. It’s frustrating to trace variables to find their source. If a class interacts with a signal, it should be provided with a reference to it.

I'll try to clarify. The problem of interaction between components and their response to data changes, in my opinion, lies not in how they receive the data but in how to avoid using global variables. I would like to see at least one example added to your article where this issue is addressed.

I noticed that the created components rely on the global variable cart, which is probably not a good practice.

Signals don’t seem ideal, though the idea isn’t bad. Implementation might fail, e.g., when removing a web component from the DOM. As for nanostores, I can’t say much yet; I need to read more. At the moment, I’m using a connector-adapter pattern. It works, but there’s always room for improvement.

Regarding the article's topic, I enjoy reading content that aligns with my own thoughts. Thank you, I will explore it further. However, I have an immediate question: what if there are two or more data sources?

The link named "use events-based providers" points to the localhost

Data Models and Web Components Picture this: you've probably heard about web components multiple times — their magic, their unique...

A big thank you, @tonydewan.com , for inspiring me to write a series of articles on how #WebComponents can work with data. Here is the first of these articles.

dev.to/valkoivo/dat...

No, a blob is not a good option. On top of that, it needs to be escaped.

A similar issue occurs when we need to pass a complex combination of characters into a component, as with onClick. In such cases, we use addEventListener, which is better in many ways.

Yes, and while this is a great solution, the entity generating the HTML still needs to be aware of the data structure to pass it to the component. However, I believe that only the component and the data model should have knowledge of the structure.

Let me try. Imagine the <ul> component. It may contain a set of <li> elements, but the responsibility for managing these <li> doesn’t fall on the <ul> itself but on the system that contains the <ul>. While this reduces the complexity of data, it compromises the encapsulation of <ul> behavior.

Well, that's great. Now I'll think about how to convert all the bind to arrow functions. The evening was starting off so well...

'...the arrow function doesn't create an additional function object on every call... bind creates a new bound function every time...'