Modals and Notifications are components that are appended to the body. So they work little different than normal components. In my App, I can think of two ways of implementing them and I am not sure which one is better.
No stores
In this approach, I create a NotificationHelper class which has a create method. Inside that, I create a new container node, append it to the body and then call React.render(, container);
So any component can call NotificationHelper.create() and it will create a notification. Notification component that manages it's lifecycle and closes when the timer expires or somebody clicks on the close button.
The problem is often times, I need to show notification on the page in response to XHR response (success or failure), so in my actionCreator, I will have code like this
APIManager.post(url, postData).then(function(response) {
NotificationHelper.create(<SuccessNotification />)
});
I don't know if it's correct to call something like this from action creator that renders a new component.
With stores
Another approach is to create a NotificationStore and on emitChange render the notification component.
The code will look something like this
In my App.js, the code will be
<body>
<Header />
<Fooder />
<NotificationContainer />
</body>
And then in NotificationContainer, I will do something like
onChange: function() {
this.setState({customNotification: NotificationStore.get()});
},
render: function() {
<Notification>
{this.state.customNotification}
</Notification>
}
And finally, the action creator will look something like
Dispatcher.dispatch({
actionType: 'notification',
component: <MyComponent/>
});
The problem with this approach is the additional overhead of stores. Store is not doing any meaningful thing here, it's only there just to follow the flux. From action creator, we are passing data to the store, and the component is again taking the same data from the store and rendering it. So we finish the flux cycle without really getting anything out of it.
Also, I now need to initialize NotificationContainer at the start of my app, even though I don't have any notifications at this point.
I don't really see how your problems are problems. It does exactly what it's supposed to do, and if you need to build on it later, you can easily do so. Notifications and other no-true-component-owner features are one of the best reasons to use flux in my opinion (90% of the time I don't recommend flux).
With flux the notification action creator would be responsible for creating a remove notification action after a set period of time. You can also have an x button on the notification, which when clicked creates that action, and these go to the store which removes the item if it exists, and any/all views dependant on this store update. When I say any/all I mean that the notifications component may be hidden, or there may be an alternate way to view notifications on one page of the app, or there may be a simple counter with the number of notifications anywhere in the app.
Side note: don't pass around elements in a way that they could be rendered more than once. Pass {component: SuccessNotification, props: props} instead if you need to specify the component ahead of time.
I follow the answer of FakeRainBrigand.
Sorry the self promotion here but I created a Notification component that you can use with Flux. Here you can see a issue that shows a example of usage with Alt, but the principles are the same. You add the component to a top level element on your HTML and subscribe that component to a Notification store. On your notification action creator, you can add notification with some properties like: level, position, auto-dismissible, action, etc.
Here is the component demo.
Related
I have an issue on any page within a specific domain, where for every page load I have two Container Loaded events. Now this wouldn't bother me normally, but the DataLayer object I need only loads in the second gtm.start event, while my tag fires on the first gtm.start, so that the DLV is undefined when I need it.
Can I do anything GTM-side so that the DLV populates on the first Container Loaded event?
enter image description here
The container loaded more times than needed.
I think the problem is your website has 3 GTM installed. So the sequence here is very important.
You might need to check with your engineer or you can do it yourslef.
Currently the order looks like:
GTM-A.js
Datalayer you need
GTM-B.js
GTM-C.js
So I would recommend your order should adjust to
Datalayer you need
GTM-A.js
GTM-B.js
GTM-C.js
The core idea is make your datalayer push before any gtm.js code. This would make sure the GTM containers detect the datalayer you need when loading.
Otherwise. Make the datalayer push with an event name. So you can make your page_view event with that datalayer event.
But not very recommend this way. Only if you can not modify the order.
We are working on tracking a site which has components built using Shadow DOM concepts, when we are creating a rule in launch to add tagging to these components it’s not working.
Can you guide us with best practice on tagging components in Shadow DOM?
I found unanswered questions about google analytics Google analytics inside shadow DOM doesn't work is this true for adobe analytics also?
Best Practice
Firstly, the spirit of using Shadow DOM concepts is to provide scope/closure for web components, so that people can't just go poking at them and messing them up. In principle, it is similar to having a local scoped variable inside a function that a higher scope can't touch. In practice, it is possible to get around this "wall" and have your way with it, but it breaks the "spirit" of shadow DOM, which IMO is bad practice.
So, if I were to advise some best practice about any of this, my first advice is to as much as possible, respect the spirit of web components that utilize shadow DOM, and treat them like the black box they strive to be. Meaning, you should go to the web developers in charge of the web component and ask them to provide an interface for you to use.
For example, Adobe Launch has the ability to listen for custom events broadcast to the (light) DOM, so the site developers can add to their web component, create a custom event and broadcast it on click of the button.
Note: Launch's custom event listener will only listen for custom event broadcasts starting at document.body, not document, so make sure to create and broadcast custom events on document.body or deeper.
"But the devs won't do anything so I have to take matters into my own hands..."
Sadly, this is a reality more often than not, so you gotta do what you gotta do. If this is the case, well, Launch does not currently have any native features to really make life easier for you in this regard (for the "core" part of the below stuff, anyways), and as of this post, AFAIK there are no public extensions that offer anything for this, either. But that doesn't mean you're SoL.
But I want to state that I'm not sure I would be quick to call the rest of this answer "Best Practice" so much as "It's 'a' solution..". Mostly because this largely involves just dumping a lot of pure javascript into a custom code box and calling it a day, which is more of a "catch-all, last resort" solution.
Meanwhile, in general, it's best practice to avoid using custom code boxes when it comes to tag managers unless you have to. The whole point of tag managers is to abstract away the code.
I think the TL;DR here is basically me reiterating this something that should ideally be put on the site devs' plate to do. But if you still really need to do it all in Launch because ReasonsTM, keep on reading.
'A' Solution...
Note: This is a really basic example with a simple open-mode shadow DOM scenario - in reality your scenario is almost certainly a lot more complex. I expect you to know what you're doing with javascript if you're diving into this!
Let's say you have the following on the page. Simple example of a custom html element with a button added to its shadow DOM.
<script>
class MyComponent extends HTMLElement {
constructor() {
super();
this._shadowRoot = this.attachShadow({
mode: 'open'
});
var button = document.createElement('button');
button.id = 'myButton';
button.value = 'my button value';
button.innerText = 'My Button';
this._shadowRoot.appendChild(button);
}
}
customElements.define('my-component', MyComponent);
</script>
<my-component id='myComponentContainer'></my-component>
Let's say you want to trigger a rule when a visitor clicks on the button.
Quick Solution Example
At this point I should probably say that you can get away with doing a Launch click event rule with query selector my-component#myComponentContainer with a custom code condition along the lines of:
return event.nativeEvent.path[0].matches('button#myButton');
Something like this should work for this scenario because there are a lot of stars aligned here:
The shadow dom is open mode, so no hacks to overwrite things
There are easily identifiable unique css selectors for both light and shadow DOM levels
You just want to listen for the click event, which bubbles up and
acts like a click happened on the shadow root's light DOM root.
In practice though, your requirements probably aren't going to be this easy. Maybe you need to attach some other event listener, such as a video play event. Unfortunately, there is no "one size fits all" solution at this point; it just depends on what your actual tracking requirements are.
But in general, the goal is pretty much the same as what you would have asked the devs to do: create and broadcast a custom (light) DOM event within the context of the shadow DOM.
Better Solution Example
Using the same component example and requirement as above, you could for example create a rule to trigger on DOM Ready. Name it something like "My Component Tracking - Core" or whatever. No conditions, unless you want to do something like check if the web component's root light DOM element exists or whatever.
Overall, this is the core code for attaching the event listener to the button and dispatching a custom event for Launch to listen for. Note, this code is based on our example component and tracking requirements above. It is unique to this example. You will need to write similar code based on your own setup.
Add a custom js container with something along the lines of this:
// get the root (light dom) element of the component
var rootElement = document.querySelector('#myComponentContainer');
if (rootElement && rootElement.shadowRoot) {
// get a reference to the component's shadow dom
var rootElementDOM = rootElement.shadowRoot;
// try and look for the button
var elem = rootElementDOM.querySelector('button#myButton');
if (elem) {
// add a click event listener to the button
elem.addEventListener('click', function(e) {
// optional payload of data to send to the custom event, e.g. the button's value
var data = {
value: e.target.value
};
// create a custom event 'MyButtonClick' to broadcast
var ev = new CustomEvent('MyButtonClick', {
detail: data
});
// broadcast the event (remember, natively, Launch can only listen for custom events starting on document.body, not document!
document.body.dispatchEvent(ev);
}, false);
}
}
From here, you can create a new rule that listens for the custom event broadcast.
Custom Event Rule Example
Rule name: My Button clicks
Events
Extension: Core
Event Type: Custom Event
Name: MyButtonClick
Custom Event Type: MyButtonClick
Elements matching the CSS selector: body
Conditions
*None for this scenario*
From here, you can set whatever Actions you want (set Adobe Analytics variables, send beacon, etc.).
Note:
In this example, I sent a data payload to the custom event. You can reference the payload in any custom (javascript) code box with event.detail, e.g. event.detail.value. You can also reference them in Launch fields with the % syntax, e.g. %event.detail.value%.
I am using Angular2 with ionic, and I have this sort of component:
class MyComponent implements OnInit, OnDestroy {
ngOnInit() {
console.log("init");
socket.on("something", this.something.bind(this));
}
ngOnDestroy() {
console.log("destroy");
socket.remove("something", this.something.bind(this));
}
}
To open this page, I write this.nav.setRoot(MyComponent). Now my page is showing MyComponent, and the socket is listening for "something".
To refresh it, I write this.nav.setRoot(MyComponent) again. Now my page is showing MyComponet, and the socket is not listening for "something".
The console output is:
init
init
destroy
Why is it first run ngOnInit of the second component, and only then ngOnDestroy of the first one?
Is there a way to first call the destroy, and then the init?
Is there another way I should handle my socket?
As I understand this, you cannot really control, what should happen first in between ngOnInit of the second component and ngOnDestroy of the first one. These hooks, from 2 different components, at least, are not dependent on each other. Whether hooks on the same component are dependent on each other. Read this.
May be, this depends on whatever gets triggered faster at the moment.
In this case, what you can do is, you can move your code from ngOnDestroy before calling this.nav.setRoot(MyComponent).
Also, if the requirement does not suite this kind of code, you can try to refresh a particular type of UI component which needs to be refreshed than refreshing the entire component like this.nav.setRoot(MyComponent).
You can refresh a particular UI component using DOM using document.getElementByID('myDiv') type of operations.
Hope this helps. If not, please mention the specifics.
Apparentally, ionic has it's own lifecycle functions, as mentioned here.
Instead of ngOnInit use ionViewDidLoad
Instead of ngOnDestoy use ionViewWillLeave
Works like magic.
I tried the example which is showing how to get data from history to re-generate UI; The thing I see mostly in all "history usage" examples are related to UI re-generation only so it is none-static way...
But what about "each UI state may have its unique url something like JSF does with flows"? For example I have app url like a
http://localhost:8080/myapp/MyApp.html
the app default UI contains main menu which is helping to navigate through my test catalog; I tried to make possible keep the UI dynamics in history by building url in this way
http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1
but when I click internet browser "refresh" button the url keeps the same as http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1 but the UI comes back to its default state :(
So my question is
is there an optimal way in pure gwt to stay in the same UI state even after browser's refresh button is clicked (I mean the unload/load window events occur)?
thanks
P.S. gwt 2.3
You should implement Activities and Places pattern: http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html
I am using it for 3 years, and it works very well.
Note, however, that when you reload a page, you lose all of your state, data, etc. If you need to preserve some of it, you can use a combination of a Place (#page1) and a token that tells the corresponding Activity the state of the View representing this Place, i.e. (#page1:item=5).
You probably just forgot to call
History.fireCurrentHistoryState();
from your entry point.
This is for an AngularJS app. I have a custom directive that depends on a service.
What I'm really curious about is the "angular way" to deal with a user action that impacts both model and DOM. Some example code:
HTML:
<form foo-places>
<!--other stuff -->
<span ng-repeat="place in places">
<button ng-click="removePlace(place)">remove {{place}}</button>
</span>
</form>
JS:
angular.module('foo.directives', []).directive('fooPlaces',
function(placesService) {
return {
controller : function($scope) {
$scope.places = placesService.places;
$scope.removePlace = function(name) {
placesService.removePlace(name);
};
$scope.$on('placesChanged', function() {
$scope.places = placesService.places;
});
},
link : function($scope, element, attrs) {
//code to do stuff when user removes a place
}
}
})
When a user removes a place (by clicking a button), I also need to do stuff to mess with the DOM, for example, scroll the window to the top, etc. It feels weird to have a function in the controller that deals with the model and then another function in the directive that does the DOM stuff...but both based on the same user action.
Am I over-thinking this or really missing something? How should I handle a single user action that deals with both model and DOM?
When you are dealing with AngularJS you might have heard the phrase "The model is the single source of truth". If you understand this part, then the rest of the things fall easily into place. This is the "Angular way".
When the user interacts - he is not interacting with the DOM or the view. He is interacting with the model. The view itself is just a "view" of the model. There could be other views of the same model - which is why the model is the single source of truth. Now, what angular allows you to do is make changes to the model when the user interacts. You make these changes and because the model has changed, the view's start reflecting the changed state of the model.
Also, just to emphasize the separation of concerns - a directive should rarely, deal with a service directly. A directive is a piece of the DOM, which means it is a piece of the view. A service generally has something to do with business logic or represents a model. In MVC or MVVM you dont directly make the View interact with the Model. You always use the ViewModel or Controller in between. This keeps the dependencies to a minimum.
Your ScrollToTop could be a service that you call from your controller (look at $anchorScroll which is a service in Angular ). It doesnt do what you want, but its a scrolling service, which is how you need to implement yours too.
EDIT :
To clarify, you dont generally do DOM manipulately stuff in services. The scenario where you could consider DOM manipulatey stuff in the service, is when, what you are trying to do does not belong to any particular html element, but something that needs to happen on your app level.
Let me explain that. For example, if you are attempting to do something like a dialog / modal window - In angularJS, you would think, the ideal place for something like this is a directive since it is a generic UI component. But if you think about it, a directive in AngularJS is something associated with an element. You always associate a directive with a html element. But as we have seen, a dialog isnt something that you attach to an element, but rather something that is global in nature. This is probably an exception.
The same also holds true to some $window and $document related stuff ( scrolling for example ). These dont belong to any particular element (if you want to scroll inside a div, it should be a directive ), hence they need to be a service. Also, this is a service you could probably inject into a directive. Say each time your directive is triggered you want to scrollToTop or open a dialog. You could inject these kind of services into your directives. The kind of services that you probably should not inject into a directive are services that are associated with business logic. Treat a directive as a re-usable UI component.
Ofcourse, you could create a higher level component ( the stuff you are trying ) which creates a DSL, but then you need to know exactly what you are doing. Until then, I suggest you stick with the plain old controller, directive and services and each managing their own concerns.