According to the Vue 3.0 guide:
Methods called from a template should not have any side effects, such
as changing data or triggering asynchronous processes. If you find
yourself tempted to do that you should probably use a lifecycle hook
instead.
I'm curious why this is? I feel like it's very likely you'll want to change data on an event listener that references your own method rather than a lifecycle hook.
I think what they mean is you should not call a method with side effects during the render, like this:
<div :title="changeSomeData()">Hello</div>
One such problem with this is calling changeSomeData() during the render can mutate reactive data which will trigger another re-render of the component, potentially infinitely. It's not good code.
It isn't always clear to the programmer when the component will be re-rendered and thus when changeSomeData() will be called. This makes it difficult to trace the cause of some data mutation.
An event handler method is not executed during the render, instead it is only registered as an event handler and will be called later in response to that particular event. This is OK.
They means the methods used for rendering purposes like :
<p>
{{showSomeCalcul()}}
</p>
because the methods are used as handler for events :
<button #clikc="send" >Send</button>
Related
I've seen this blog post claim that using properties to pass callbacks is an anti-pattern in Vue.js
But it doesn't make sense to me. The problems mentioned:
By passing functions down as props, you are linking both parent child components together with two-way data binding
These events are mechanically doing the exact same thing as a callback prop, so this doesn't add up.
As the application grows larger in size and other developers come on board, they will look at the child component code and have to figure out which callback function prop it is and where it is from.
You can replace the word callback function prop with event and you get the same problem.
Using functions instead of string names would avoid the kebab-case issue. Also, function-props would allow typescript to verify the function signatures are compatible. I think events should be removed and replaced entirely with callback props. The only downside I see for removing the events tech is a namespacing issue for events like click that you might want as properties.
What are the design reasons for including events as a system instead of having a few magic properties? Are callback properties an anti-pattern or is it just a matter of taste?
AngularJS official documentation provided the following information in this regard.
$doCheck() - Called on each turn of the digest cycle. Provides an opportunity to detect and act on changes. Any actions that you wish to take in response to the changes that you detect must be invoked from this hook; implementing this has no effect on when $onChanges is called. For example, this hook could be useful if you wish to perform a deep equality check, or to check a Date object, changes to which would not be detected by Angular's change detector and thus not trigger $onChanges. This hook is invoked with no arguments; if detecting changes, you must store the previous value(s) for comparison to the current values.
I've explored on the web but could not find any information related to how calling $onChanges will makes the calls to $doCheck void. Someone please provide more information.
The $onChanges and $doCheck hook can easily live side-by-side. The $doCheck hook doesn't effect the $onChanges hook at all. Of course fields checked in the $doCheck hook no longer need to be handled in the $onChanges hook. In Angular 2 it’s even recommended to not use these 2 hooks together.
I'm setting up a site using react.js. the client receives a massive json through ajax that is then used to populate all the necessary fields, graphs, etc. Seeing as this json will cover pretty much all the information contained on the site, it has be accesible in almost every single component. Is there a clean way to pass it to every last component (and there are a lot of them)? Passing it the regular way to ~70 components seems dirty and inefficient.
As React's documentation states, you could have components communicate by integrate a global event system, and then subscribe to an application-data event from all your components, in componentDidMount().
This way, each time you will emit the application-data event from within the code responsible for pulling the website data, all components will receive that data. At that point, you can call setState().
Please be careful and unbind the events once a component goes "out of scope", inside componentWillUnmount().
Failing to do so will result in memory leaks, as you will have the event handler dangling, and it will be called each time you pull the website data, even if your Component's instance has been removed from the DOM.
You could also try to make your components pull data by themselves, as sending a huge JSON around, is not the best solution. I mean, each component should use the data it needs, in order to work, not the whole website data. The way I would alter this would be by parsing the JSON object and storing it for reference in a variable, on a scope that is accessible to all components, and use the event system to only notify the components that the data is ready, and each component would go to the global data object and get their data.
Example(pseudo-code):
XHR.getData
XHR.onReadyState => GlobalNameSpace.data = data
EventSystem.PUBLISH('application-data')
// component code
Component {
EventSystem.SUBSCRIBE('application-data') =>
dataNeededForInit = GlobalNameSpace.data.componentXData
}
Reference: https://facebook.github.io/react/tips/communicate-between-components.html
Context might fit the bill. It might not be particularly tidy solution but perhaps that would be a starting point for you.
I recently started trying out Ractive.js. I was particularly interested in its components. One of the things I noticed immediately is that many of the examples are using the init option. However when I try to use the init in my code I get a deprecation notice and it then recommends using onrender instead. onrender however had far fewer examples than init and some of the functions such as this.find weren't available inside onrender. I looked through the Github issues but couldn't find any reasoning behind this change or what the suggested path forward for selecting elements specific to a component was.
I created a test pen to try creating a recursive component with the new API but I had to resort to using jQuery and an undocumented fragment api to select specific DOM nodes I needed to manipulate. I feel this is against how Ractive expects you to do things, but I couldn't figure out what was expected of me with the existing documentation.
What's the major differences between the init and onrender options and how does onrender expect you to handle manipulating specific elements and their events within a component?
You can use this.find() inside onrender (if you can't for some reason, you've found a bug!).
We split init into oninit and onrender a while back for a number of reasons. Those examples you mention are out of date - are they somewhere on ractivejs.org? If so we should fix them. You can find more information about lifecycle events here on the docs, but the basic difference is this:
init was called on initial render (assuming the component was rendered, i.e. never in node.js, if you were doing server-side rendering)
oninit is called on creation, immediately before rendering. It is called once and only once for any Ractive instance, whether or not it gets rendered. It's therefore a good place to set up event handlers etc. The opposite of oninit is onteardown, so you can use that handler to do any cleanup if necessary (or use this.on('teardown'...) inside oninit).
onrender is called whenever a component is rendered. This could happen more than once (if you unrendered, then re-rendered, etc) or not at all. If you need to store DOM references etc, this is the place. The opposite of onrender is onunrender.
I did a fork of your codepen, replacing the jQuery stuff with more idiomatic Ractive code to show how you'd do it without storing DOM references.
I've inherited a rather large Javascript/ExtJS3 code base, and there are many instances of invoking events inside of the overridden initComponent method, after the call to "...superclass.initComponent.apply(this, arguments)". Specific events are being invoked on specific objects in a manner such as the following:
this.filter.on('filterUpdated', function(filter, params)
I've started converting the code to use a pub/sub paradigm instead, to reduce the coupling between objects and their specific event names, but quickly ran into issues when publishing and/or subscribing to events within initComponent (which in ExtJS executes before rendering). I need to fire an "INIT" event from the highest level component when the screen first loads, and I was either getting an error (due to ExtJS "templates" not having been rendered as it turns out), or events not firing at all.
Then I read the following in the ExtJS source for Ext.Component (from which all components extend) and I had an "aha" moment:
if (this.tpl) {
if (!this.tpl.compile) {
this.tpl = new Ext.XTemplate(this.tpl);
}
if (this.data) {
this.tpl[this.tplWriteMode](contentTarget, this.data);
delete this.data;
}
}
this.afterRender(this.container);
When I switched to both publishing the "INIT" event from my topmost component's afterRender method, and subscribing to all events from all other components from their afterRender methods, everything worked as I expected. And now I am just wondering, largely to validate my design....
Is this a generally accepted way of implementing pub/sub in an event driven UI? Regardless of framework even? Namely are the following 2 good principles, or are their other ways?
"Initialization events" should get published after all sub-components have rendered
All sub-components should subscribe to all events (to be on the safe side) after they have rendered
Thanks in advance
You have to balance the overhead of event handling vs. the possibility of missing significant events. In js/DOM land state is mutable.
For your #1 if you can identify a point in time when all your sub-components have rendered and subscribed, firing an init event makes sense.
For #2, it seems safe everyone to listen for events; however it could slow things down. If performance issues are apparent you may have to decide what events you don't care about and avoid subscribing.