I'm working on a rather complex and big project. Our QA team decided they want unique id's to do automated testing. Since our developers are rather lazy (we are developers, you know?), we are trying to inject these id's automatically.
I've tried to create a mixin that tries to add an attribute on mounted.
mounted() {
this.$el.setAttribute('data-test-id', 'a-random-id-01');
}
But this fails all the time because $el is not always available right away. Does anyone have any insight how we could do this?
Find your question from google :)
this.$el.dataset.testId = 'a-random-id-01'
Related
Hi guys so I'm new to vue and I know the basis even built my own app but I always asked my self when should I use mounted and created. I'm always concerned about optimization and right now I put all my code in created (fetching from API etc) but I was wondering when should I put for example axios calls inside mounted or created for optimization purposes etc.
You should use created unless you need access to the element this.$el (or any other element ref) then use mounted instead.
There isn't really any optimization improvement using one over the other, as long as you choose a convention and stick to it.
Max, I want to update my extension to the new format, but I am running into issues with placement of custom code. It seems that the extension framework has been updated a lot since I added an extension 4 years ago. Is there a way to get better documentation on getting started with adding a extension? I am happy to help write up the documentation if you can help answer some questions that I think would help get people started. Let me know.
The only thing that really changed is that the scaffolder creates a webpack project for you. The extension registering procedure is the same: http://js.cytoscape.org/#extensions/api
For example, cytoscape( 'collection', 'fooBar', function(){ return 'baz'; } ) registers eles.fooBar().
I guess the main thing is that there are a lot more files than what the previous scaffolder generated, so it might be harder to find things. The layout output has lots of files, because it creates a skeleton impl for each of the continuous case and the discrete case.
The scaffolder isn't strictly necessary. You could use another build system (or none at all) as long as you call cytoscape(). For example, if you only care about publishing to npm for people who use webpack/browserify/rollup, then you could just use cjs require('cytoscape') to pull in the peer dependency. Exporting a register function is nice if you want to allow the client to decide the order of extension registrations with cytoscape.use(extension) (or extension(cytoscape)).
You're right that there should be some more docs on the output of the scaffolder. Maybe a summary of the files would suffice. We could add a tutorial in the blog later if need be. Both the docs and the blog just use markdown, so the content could go in either place.
I am trying to better understand Vuejs lifecycles. The documentation is short and I guess assumes most people are familiar with the lifecycle concept.
However, I've only been using created(){} as it suits my need to initialize a function/data (to put it vaguely) when the "page is loaded".
But I am sure every lifecycle hook has its own distinct feature or purpose. So, I am hoping someone can provide a better intro/example of when each hook can be used from the context of page load to page finish.
To put it simply. When you request a web page, there are two observable steps
1: page is loading
2: page finished loading.
My question is, when do the created, mounted, updated and destroyed hooks take place within those two stages? I didn't mention the before/after hooks as they are obvious by their meaning.
Lifecycle hooks relate to a Vue instance, not to a page load. Components are Vue instances, as is the main Vue instance that is typically called on the whole page.
The diagram gives a pretty good rundown of where each hook sits in relation to what is going on on the instance. In simple terms, created happens before you have DOM to work with, and all the others happen after.
When I look at my application state in Vue's devtools chrome extension, I can see multiple instances of the same component in the tree view. However, there is no way to distinguish one instance from another. For example, in the screenshot below there are three <Todo> components. Imagine instead there are 30. How do I attach some kind of instance name or id to my components? It seems silly to have to click through 30 components to find the one I need.
I had the same idea also a couple of months ago.
So I gave it a try.
My PR has been submitted: https://github.com/vuejs/vue-devtools/pull/331
It's probably a bit early to rely on my solution since the core team could still reject the PR or request other naming conventions.
Until then you can build my proposal version yourself from my repo:
https://github.com/nerdyglasses/vue-devtools/tree/verbose-component-tree
Is that helping you?
Best, Christian
You can use the ':key' attribute. And you even HAVE TO use it if your component depends on a v-for loop.
here you can see the keys
I find, even when assigning the decorator #singleton(false) to the view-model, that while the view-model does then persist as a singleton across activation/deactivation, the bindings and components, etc do not.
(I assume this is because they are stored in a container that is disposed on deactivation.)
The result is that upon every deactivation/activation of a view with a singleton view-model, the view is un-bound and then re-bound.
Is it possible to cause the bindings to persist across deactivation/activation?
This one stumped me for a good while. It also confused me as to why implementing it was not a higher priority for the Aurelia Team.
This takes a fair amount of code to get working. I have put the code in a Gist here: https://gist.github.com/Vaccano/1e862b9318f4f0a9a8e1176ff4fb727e
All the files are new ones except the last, which is a modification to your main.ts file. Also, all my code is in Typescript. If you are using Javascript you will have to translate it.
The basic idea behind it is that you cache the view and the view model. And your replace the router with a caching router. So when the user navigates back to your page, it checks first to see if there is a view/view model already created and uses that instead of making a new one.
NOTE: This is not "component" level code. That means I have tested that this works for the scenario that I use it for.
I got my start for making this change here: https://github.com/aurelia/router/issues/173 There is another user (Scapal) made something that works for him and posted it there. If what I am posting does not work for you, his may help you out.
i'm also interested in an answer to this.
maybe i'm now making a complete fool out of me but why not use aurelia-history navigate(..) command?