I'm trying to use native web components for one of my UI project and for this project, I'm not using any frameworks or libraries like Polymer etc. I would like to know is there any best way or other way to communicate between two web components like we do in angularjs/angular (like the message bus concept).
Currently in UI web-components, I'm using dispatchevent for publishing data and for receiving data, I'm using addeventlistener.
For example, there are 2 web-components, ChatForm and ChatHistory.
// chatform webcomponent on submit text, publish chattext data
this.dispatchEvent(new CustomEvent('chatText', {detail: chattext}));
// chathistory webcomponent, receive chattext data and append it to chat list
this.chatFormEle.addEventListener('chatText', (v) => {console.log(v.detail);});
Please let me know what other ways work for this purpose. Any good library like postaljs etc. that can easily integrate with native UI web components.
If you look at Web Components as being like built in components like <div> and <audio> then you can answer your own question. The components do not talk to each other.
Once you start allowing components to talk directly to each other then you don't really have components you have a system that is tied together and you can not use Component A without Component B. This is tied too tightly together.
Instead, inside the parent code that owns the two components, you add code that allows you to receive events from component A and call functions or set parameters in Component B, and the other way around.
Having said that there are two exceptions to this rule with built in components:
The <label> tag: It uses the for attribute to take in an ID of another component and, if set and valid, then it passes focus on to the other component when you click on the <label>
The <form> tag: This looks for form elements that are children to gather the data needed to post the form.
But both of these are still not TIED to anything. The <label> is told the recipient of the focus event and only passes it along if the ID is set and valid or to the first form element as a child. And the <form> element does not care what child elements exist or how many it just goes through all of its descendants finding elements that are form elements and grabs their value property.
But as a general rule you should avoid having one sibling component talk directly to another sibling. The methods of cross communications in the two examples above are probably the only exceptions.
Instead your parent code should listen for events and call functions or set properties.
Yes, you can wrap that functionality in an new, parent, component, but please save yourself a ton of grief and avoid spaghetti code.
As a general rule I never allow siblings elements to talk to each other and the only way they can talk to their parents is through events. Parents can talk directly to their children through attributes, properties and functions. But it should be avoided in all other conditions.
Working example
In your parent code (html/css) you should subscribe to events emited by <chat-form> and send event data to <chat-history> by execute its methods (add in below example)
// WEB COMPONENT 1: chat-form
customElements.define('chat-form', class extends HTMLElement {
connectedCallback() {
this.innerHTML = `Form<br><input id="msg" value="abc"/>
<button id="btn">send</button>`;
btn.onclick = () => {
// alternative to below code
// use this.onsend() or non recommended eval(this.getAttribute('onsend'))
this.dispatchEvent(new CustomEvent('send',{detail: {message: msg.value} }))
msg.value = '';
}
}
})
// WEB COMPONENT 2: chat-history
customElements.define('chat-history', class extends HTMLElement {
add(msg) {
let s = ""
this.messages = [...(this.messages || []), msg];
for (let m of this.messages) s += `<li>${m}</li>`
this.innerHTML = `<div><br>History<ul>${s}</ul></div>`
}
})
// -----------------
// PARENT CODE
// (e.g. in index.html which use above two WebComponents)
// Parent must just subscribe chat-form send event, and when
// receive message then it shoud give it to chat-history add method
// -----------------
myChatForm.addEventListener('send', e => {
myChatHistory.add(e.detail.message)
});
body {background: white}
<h3>Hello!</h3>
<chat-form id="myChatForm"></chat-form>
<div>Type something</div>
<chat-history id="myChatHistory"></chat-history>
+1 for both other answers, Events are the best because then Components are loosly
coupled
Also see: https://pm.dartus.fr/blog/a-complete-guide-on-shadow-dom-and-event-propagation/
Note that in the detail of a Custom Event you can send anything you want.
Event driven function execution:
So I use (psuedo code):
Elements that define a Solitaire/Freecell game:
-> game Element
-> pile Element
-> slot Element
-> card element
-> pile Element
-> slot Element
-> empty
When a card (dragged by the user) needs to be moved to another pile,
it sends an Event (bubbling up the DOM to the game element)
//triggered by .dragend Event
card.say(___FINDSLOT___, {
id,
reply: slot => card.move(slot)
});
Note: reply is a function definition
Because all piles where told to listen for ___FINDSLOT___ Events at the game element ...
pile.on(game, ___FINDSLOT___, evt => {
let foundslot = pile.free(evt.detail.id);
if (foundslot.length) evt.detail.reply(foundslot[0]);
});
Only the one pile matching the evt.detail.id responds:
!!! by executing the function card sent in evt.detail.reply
And getting technical: The function executes in pile scope!
(the above code is pseudo code!)
Why?!
Might seem complex;
The important part is that the pile element is NOT coupled to the .move() method in the card element.
The only coupling is the name of the Event: ___FINDSLOT___ !!!
That means card is always in control, and the same Event(Name) can be used for:
Where can a card go to?
What is the best location?
Which card in the river pile makes a Full-House?
...
In my E-lements code pile isn't coupled to evt.detail.id either,
CustomEvents only send functions
.say() and .on() are my custom methods (on every element) for dispatchEvent and addEventListener
I now have a handfull of E-lements that can be used to create any card game
No need for any libraries, write your own 'Message Bus'
My element.on() method is only a few lines of code wrapped around the addEventListener function, so they can easily be removed:
$Element_addEventListener(
name,
func,
options = {}
) {
let BigBrotherFunc = evt => { // wrap every Listener function
if (evt.detail && evt.detail.reply) {
el.warn(`can catch ALL replies '${evt.type}' here`, evt);
}
func(evt);
}
el.addEventListener(name, BigBrotherFunc, options);
return [name, () => el.removeEventListener(name, BigBrotherFunc)];
},
on(
//!! no parameter defintions, because function uses ...arguments
) {
let args = [...arguments]; // get arguments array
let target = el; // default target is current element
if (args[0] instanceof HTMLElement) target = args.shift(); // if first element is another element, take it out the args array
args[0] = ___eventName(args[0]) || args[0]; // proces eventNR
$Element_ListenersArray.push(target.$Element_addEventListener(...args));
},
.say( ) is a oneliner:
say(
eventNR,
detail, //todo some default something here ??
options = {
detail,
bubbles: 1, // event bubbles UP the DOM
composed: 1, // !!! required so Event bubbles through the shadowDOM boundaries
}
) {
el.dispatchEvent(new CustomEvent(___eventName(eventNR) || eventNR, options));
},
Custom Events is the best solution if you want to deal with loosely coupled custom elements.
On the contrary if one custom element know the other by its reference, it can invoke its custom property or method:
//in chatForm element
chatHistory.attachedForm = this
chatHistory.addMessage( message )
chatHistory.api.addMessage( message )
In the last example above communication is done through a dedecated object exposed via the api property.
You could also use a mix of Events (in one way) and Methods (in the other way) depending on how custom elements are linked.
Lastly in some situations where messages are basic, you could communicate (string) data via HTML attributes:
chatHistory.setAttributes( 'chat', 'active' )
chatHistory.dataset.username = `$(this.name)`
I faced the same issue and as I couldn't find any fitting library I decided to write one on my own.
So here you go: https://www.npmjs.com/package/seawasp
SeaWasp is a WebRTC data layer which allows communication between components (or frameworks etc).
You simply import it, register a connection (aka tentacle ;) ) and you can send and receive messages.
I'm actively working on it so if you have any feedback /needed features, just tell me :).
For the case where the parent and child know about each other, like in a toaster example.
<toaster-host>
<toast-msg show-for='5s'>Success</toast-msg>
</toaster-host>
Lots of options but for:
Parent passing data to the child -> attributes or observedAttributes for primitives. If complex objects need to be passed either expose a function or a property aka domProperty that can be set. If a domProperty needs to react to being updated, it can be wrapped in a proxy.
Child passing data to parent -> can use events, or can query for the parent using .closest('toaster-host') and call a function or set a property. I prefer to query and call a function. Typescript helps with this type of approach.
In cases like the toaster example, the toaster-host and the toast-item will always be used together, so the argument about loose coupling is academic at best. They are different elements mainly because they have different jobs. If you wanted to swap out implementations of the toast-msg you could do that when you define the custom element, or even by changing the import statement to point to a different file.
Related
I would like to record all events that are fired through user action on DOM elements. A feature like recording user actions (macro) on my website so the app can later re-generate the current state by executing use actions sequentially. How to do it?
Is there any API or solution to find all events that are processed by event listeners?
Or should I gather events by myself? If so, what would be your approach/solution/design?
this OP says no: https://stackoverflow.com/a/63346192/5078847
It would be technically possible to record such a thing by
(1) using addEventListener exclusively in your site's code (if you don't, you'll have to also iterate through all on- properties and scan for inline handlers too, which is quite a pain)
(2) Overwrite the addEventListener prototype with a custom hander that, when fired, stores information uniquely identifying the click in an array (for example, save the name of the event fired, and a full selector string to the element the event is dispatched to, and if you need it, also the amount of time since the page was loaded)
(3) When needed, save the array somewhere
(4) To emulate the user's prior actions, retrieve the array, then iterate through it. For each action, create and dispatch an event to the unique selector at the time required.
But this is really, really convoluted. It would make a lot more sense for there to be a single source of truth for what's being displayed on your page. To save a state, just serialize the object that holds the data. To resume a state, retrieve the object and render according to its contents.
There isn't anything built in, like the other post said. Chrome devtools has a function getEventListeners that gets all the handlers for a given element (singular). You also can't use this outside of Chrome's devtools.
You could (but shouldn't) hijack addEventListener from the prototype chain.
Based off of this old forum here
/** !! Foot-Gun !! **/
/** Proof of Concept/Probably Doesn't Work **/
HTMLElement.prototype._addEventListener = HTMLElement.prototype.addEventListener;
HTMLElement.prototype.addEventListener = function(eventName, handlerFunction, eventOptions) {
// reportFunction you would have to write yourself
this._addEventListener(eventName, reportFunction, eventOptions);
this._addEventListener(eventName, handlerFunction, eventOptions);
// Store an array of them on the element
if ('currentListeners' in this === false) {
this.currentListeners = [
{ eventName, handlerFunction, eventOptions }
];
} else {
this.currentListeners.push({ eventName, handlerFunction, eventOptions });
}
}
Granted, I just handed out a loaded foot-gun for anyone who wants one. It's an anti-pattern at best, it doesn't control/track state, emulate user interactions, etc. etc.
I wouldn't recommend this for "regenerating" or rerendering UI as it's gonna be more trouble than it's worth.
If you're trying to use this for debugging, there are a couple of SAAS whose whole business models are based off of this, like HotJar and Sentry.io. I'd recommend checking them out first if you're looking for a solution.
I'm creating a Javascript game that provides quests for the user to play through. Each quest has a number of tasks which are completed when certain requirements are met. Below is the design I originally intended to go with.
As you can see, each Task and GameEvent (simplified to Event) has a type and some data (encapsulated in a dict). When an event is sent to QuestManager, it is passed along to the active Quest objects who in turn pass it on to each Task assuming their types are the same. Each requirement in the task is then tested against the correlating data in the event. The reason why I don't do 1:1 checks is because an event may have additional data.
e.g data{item: someItem, locationFound: someLocation} != requirement{item: someItem}
This works great in terms of minimising the number of classes that need to be created. Events and tasks are generic so they can be easily created and tested against without creating a ton of sub-classes.
But this design creates a problem. Because of its generality, it is never certain what requirements should be given to a task without first finding an event of the same type and checking the data being sent to it. As the project expands, this becomes a nightmare to manage.
Instead, I could create sub-classes for both Event and Task that would cover the various types, like this:
Event -> ItemPickupEvent, MoveEvent, etc.
Task -> ItemPickupTask, ItemPickedUpAtLocationTask, MoveTask, etc.
But the data is similar between them and seems highly unnecessary.
My final thought was to create data objects to encapsulate the data being passed by certain event types, as follows:
ItemPickupData, MoveData, TalkData etc.
Events and tasks could just be given the appropriate data object. This provides better structure to the data being used. If a piece of data should not be made into a requirement, it could simply be defaulted to null.
In terms of maintainability and structural design, is this an adequate solution or is there a better way to approach this problem?
Thanks.
Because of its generality, it is never certain what requirements should be given to a task without first finding an event of the same type and checking the data being sent to it.
As I understand, the problem is that almost the same data is duplicated in the event object and task object.
For example, you have Event { 'type': 'ItemPickup', data: { 'name': 'MagicSword', 'kind': 'weapon' } }.
And then you want to add a task to pickup the magic sword and you create the Task { 'type': 'ItemPickup', data: { 'name': 'MagicSword' } }.
So this is the problem and here you need to lookup how exactly you have configured the event and put the same data into the task object.
I think the solution to move this data into separate objects should work well.
Another thing which doesn't look right is that you have type field and it hints that you need to have subclasses.
And this also would be solved if you create the data objects like ItemPickupData, MoveData, etc.
An alternative can be to have the Event itself to be this data object and have something like this (pseudocode):
class Event // base class for events with common data and methods
// the subclasses can be almost empty
class ItemPickupEvent extends Event
class MoveEvent extends Event
class Task
_requirements = [
new ItemPickupEvent('MagicSword'),
// and maybe it is even better to wrap events into "Requirment" objects,
// which can, for example, be marked as completed
new Requirement(new MoveEvent('OldForest')),
...
]
And then you could then manage requirements this way:
class Task
isComplete(event)
complete = false
// go over requirements to see if this task is complete
for requirement in this._requirments:
complete = complete && requirement->isComplete(event)
return complete
class Requirement
isComplete(event)
# check event class and properties to understand if the requirement is satisfied
if class(event) == class(this._event):
if event.isNameMatches(this._event):
this->_complete = true
return this->_complete
It can also be done without the class name check.
The idea is to have base Requirement class has special methods for each event class and rejects them by default.
Subclasses then can handle specific event types:
class Requirement
isComplete(event)
// redirect the type detection to event object
return event->isComplete(this)
isCompleteItemPickup(event)
return false
isCompleteMove(event)
return false
class ItemPickupRequirement
isCompleteItemPickup(event)
// here we know that event is ItemPickupEvent
if event.isNameMatches(this._event):
this->_complete = true
return this->_complete
class MoveRequirement
isCompleteItemPickup(event)
// here we know that event is MoveEvent
if event.isNameMatches(this._event):
this->_complete = true
return this->_complete
The isComplete method of the Requirment class is used from the Task class and it re-directs type detection to the event object.
The event object then passes itself back to the appropriate method of the requirement:
class Event
isComplete(requirement) // should be implemented in subclasses
class ItemPickupEvent
isComplete(requirement)
// here we call the specific requirement method
// now we know the exact event object type (it is ItemPickupEvent)
return requirement->isCompleteItemPickup(this)
class MoveEvent
isComplete(requirement)
return requirement->isCompleteMove(this)
The structure may look a bit complicated, but depending on the specifics, you may need the Requirement class and it's sub-classes anyway (for example, there can be generic ItemPickupRequirement and some specific PowerItemPickupRequirement).
I'm looking into breaking a large UI component into smaller pieces, but one thing I'm not entirely sure how to handle and something that I can't seem to find general info about is delegating events from sub-components.
Lets say, for example, you have a todo list and clicking on a todo list will update a sidebar with details about the todo. Right now the code we have is basically 1 file with a template and does all the events for everything. It searches in DOM nodes for data when you click on the delegated handler attached to the wrapper of the list and sidebar. There is potentially thousands of clickable rows.
I'd like something instead that is along the lines of this (this is just pseudo code):
app.controllers.todos = library.controller.extend({
init: function () {
// Store all the todo items in an array
this.todoItems = [];
todoItemsReturnedFromServer.forEach(function (data) {
var todoItem = new app.todo.item(data);
todoItems.push(todoItem);
});
this.todoList = new app.todo.list({data: this.todoItems}); // start with initial data
this.sidebar = new app.sidebar();
},
render: function () {
$('#wrapper').append(this.todoList.render());
$('#sidebar').append(this.sidebar.render());
}
});
So, you'd have a todoList component you could add/remove from and you could have events hooked up which could update the DOM, but is decoupled from the data (i.e. you could not have any DOM and it'd work). Now, in our app, if you click on a todoItem, the todoItem needs to delegate it's event to todoList or higher. I don't want to have 1 click event for every todoItem.
My only idea is to have a "delegate" property on the sub component that the parent takes (if supported) and creates events from. It'd have a hash of events and handlers. If the event handler is already attached it simply ignores it.
Are there other examples or patterns for this type of thing?
Have you tried to use a client-side MVC framework? These are created to solve such problems. I would suggest starting with backbone.js.
Here is a great introductory book. It deals with nested views and models, too:
http://addyosmani.github.io/backbone-fundamentals/#working-with-nested-views
http://addyosmani.github.io/backbone-fundamentals/#managing-models-in-nested-views
http://addyosmani.github.io/backbone-fundamentals/#working-with-nested-models-or-collections
I'm going through the leaderboard example right now, and I've finished it, but I'm not fully satisfied with my implementation of the add functionality.
To start with, we have
Template.player.events({
'click': function () {
Session.set("selected_player", this._id);
}
});
I find it a little bit confusing how this is associated with the player collection, but I imagine this has to do with the <template part. I am also able to do
Template.leaderboard.events({
'click input.delete': function () {
Players.remove(this._id);
}
...which does remove the player with the associated button entry.
Now for the actual question part: I have added this to the bottom of the leaderboard template:
<div>
Add player: (Name <input required name="name" id="name">)
(Score <input required name="score" id="score">)
<input class="add" type="button" value="Add">
</div>
This works fine, and I have Template.leaderboard.events['click input.delete'] working fine, but in order to get the values I use:
'click input.add': function () {
var name = document.getElementById('name').value,
score = document.getElementById('score').value;
It would make a lot of sense to me if I were able to use this in some way, or use the event to somehow get the values that correspond the inputs. This not only makes sense to me from a design standpoint, but it would also cover the case of having more than one of these kinds of forms displaying simultaneously.
So in short is there any way to get elements that are near the target element in the context of an event?
Every event handler is given two arguments: event and template. You can read more about these event handler arguments here: http://docs.meteor.com/#eventmaps
event.target is a reference to the DOM element that originated the event. You can then use something like jQuery's traversing functions to get an element nearby.
You could also set the input values as properties of the template instance. E.g. in the template's created handler, you create name and score properties:
Template.player.created = function() {
this.name = '';
this.score = '';
};
And then you update those values in the keyup events of your input textboxes:
'keyup #name': function(event, template) {
template.name = event.target.value;
},
'keyup #score': function(event, template) {
template.score = event.target.value;
}
This is the way the same way that widgets made for Ember update their values, as explained here: http://www.emberist.com/2012/04/12/two-way-binding-to-the-dom.html
Nice to see someone with so much street cred using Meteor! The best way to get the value is with event.currentTarget and to get stuff from the data contexts there is also another way which needs no DOM knowledge
Template.player.events({
'keypress #name':function(event,context) {
//Get the event sending this' value
console.log(event.currentTarget.value)
//Traverse the DOM on the template 'player' in this case
console.log(context.find('#score').value)
}
});
Basically the best way to get the value of the sender is to use event.currentTarget to access the DOM for that object sending the event.
The reason it's implemented this way is probably because any dom object can send an event and it won't necessarily always have a value field so a slight bit of knowledge of the DOM is required when handling the event maps but using event.currentTarget.value works for most form fields
Data contexts
Regarding the data contexts you should be able to use the data available in the templates from the helpers, e.g if theres a {{score}} & a {{name}} value in the template or a helper, which is passed in this case via the {{#each}} for each individual player.
this.name,
this.score;
Which is also the same as (I usually use context in my helper but template is another way of callng it i guess like in travellingprog's answer)
context.data.name,
context.data.score;
The this helps get data from the template's data context into event's so that one doesn't have to use hidden HTML attributes containing data, e.g with how the player is removed its a bit cleaner than storing the _id in the dom somewhere. That being said event.currentTarget or context.find(..) are the best way to get the data from a textfield.
This seems possible as http://www.knockoutjs.com appears to be doing it. I haven't been able to make enough sense of their code-base to get a similar pattern working though.
Effectively I have a MVVM style application with the UI based on jQuery tabs. Each tab is represented by a view model that I want to be able to validate and fire events based on changes in the model.
I create a representation of my data similar to the following on page load:
$(document).ready(function(){
thisTab = new ThisTab();
});
function ThisTab(){
Load: {Load from my model}
Save: {Save/Persist model to the db (via web service call)}
Validate: {
this.Item1 = function(){Validate item 1, do work, refresh fields, whatever.}
}
}
The model itself is a complex global object and changes to the DOM (inputs, etc.) immediately update the object. Changes to some of those properties should call their associated validate items thisTab.Validate.Item1. I have no issue raising events from the changes. If I bind that event listener to a random DOM element I can call my routines without issue and everything works beautifully. It does seem strange, however, to attach the event to a non-related DOM object.
So the question is: how can I do something like thisTab.addEventListner("someEvent") or $(thisTab).bind("someEvent"), where thisTab is not a DOM element, but instead is a native object. Trying to do it, I always get an error that "this method is not supported".
Attaching an event to a standard object does not use the same methods; basically, you would implement your own eventing like so:
function ThisTab()
{
listeners: [],
addListener: function(callback) { this.listeners.push(callback); },
load: { // Finds DOM elements and such, and attaches to their events. The callback from the DOM event should be a method on your object },
yourDomEventCallback: function()
{
for(var j = 0; j < this.listeners.length; j++)
this.listeners[j]();
}
}
The above code should be used as a starting point, since I just cobbled it together and there are likely syntax errors. Basically, you have taken your object and mapped onto events you want to capture, and then expose methods to attach callback methods that you will call when the hidden DOM events occur. You wont be able to use jQuery's abstractions for DOM events, because such events have no meaning on your custom object.
Bind the event to your regular JS object as you would do for a DOM object.
$(thisTab).bind("someEvent", function() {
// handler's code here
});
See this example. Using this has one side-effect that jQuery will add a housekeeping identifier as a property on the object - it looks something like
jQuery1510587397349299863.
This property named jQuery<timestamp> is added to all DOM objects that have events or data associated with them, and regular objects behave similarly. If you are uncomfortable with your model objects being modified, then use your own callback mechanism which should be fairly easy to add.