I'm having a hard time understanding a few reasons of the Virtual-DOM based design.
I think I have grasped the main concept but there is still a few dark areas.
Here what i've understood : in a web application structure around VueJs for example, instead of directly manipulating the DOM, which would result in too muche re-layout/re-paint processes and would be time consuming, the dev manipulates a model of the dom, the virtual dom.
The Virtual DOM is a tree-like data structure and does not render directly.Any modification is not time consuming at all. The data of the Virtual Dom is then applied to the real dom.
My question here is on the then.
How to know when to apply the changes of the virtual dom on the real dom?
I think I've understood that a change in the dom is sometimes a "transitional state" change and that kind of change does not need to be rendered immediatly.
How to decide which change is a "real" change that need to be displayed or which change is a "transitionnal state" change that does not need to be displayed ?
Do you have an example of a "transitional state" change that does not need to be rendered?
If any change is applied, I can't see the performance earning of the virtual dom.
I sense there's something I've missed, but i can't put my finger on it. I thought one of you guys could help.
Related
I find the concept of atoms and molecules very interesting, but I can't imagin ending up with thousands of atom components, scattered all over the place. Another way of putting the question would be: when is a Vue component getting too big ? Thank you for your input.
Well it depends of a lot things, but if you see the code you're writing will be re-use more than twice i guess, it's a good idea to make as a component.
Additionnally you could think of the fact of clarity, if you're having a lot of html in your component, for readability purpose you could split this component in few pieces.
For example this component i've made, it's a Job offer,
in the blue rectangle we have the acronym of the company hiring
in the dark gray rectangle, the percentage of the the job,
a button to toggle the "card" and show the full job content,
a title of the offer and the deadline for the postulation.
When it's closed
Then when it's toggled
It was kind of a lot of html in the code so beside aving a Job offer component with everything in it, i've splitted it for readibility,
In total there is 5 component inside JobOffers
A button that i re-use everywhere in my website
The JobAcronym (blue rectangle)
The JobMeta (title + deadline + button), the middle of it
The JobPercentage (dark gray rectangle)
The JobContent, (arichtext component),visible when its toggled
Doing so, it could easily be more readable in my code, people knew which part was represented by what just reading the code.
For sure it creates more atoms and molecules, but if you create a directory named JobOffer and you put all your components required intside (appart from the button that is kind of global), it doesn't make your application difficult to read.
Even some component doesn't have a logic behind, like the JobAcronym and JobPercentage, they do contains a lot of html that could make your JobOffer component hard to read if they were inside of it.
To conclude, you really need to choose with your guts, if you see you're having trouble finding where to apply your edit to change some ui, beceause there is a lot of html code, then split it.Even if you won't re-use that component anywhere else.
What's important is the readability of your code, and it's really more easier to maintain.
So when you, or someone else come back in few months to do some updates on it, they won't loose time trying to guess which part belongs where.
I hope it answered your question and cleared some doubts you had :)
I'm writing an app in Vue and I have a really hard time understanding the component hierarchy, namely the parent-child relationships and how to pass data around.
I have a view that contains a map which in turn has some navigation controls and options that are overlayed on top of the map. Now, I want these controls to manipulate the map WITHOUT having to nest the buttons inside the actual maps as it will cause severe display issues (for example, clicking on a zoom button falls through the button and also clicks the next element under it).
My app looks like this:
Mapview
Map
Controls
Options
Optionpanel1
Optionpanel2
...
Now, a HTML input element in Optionpanel1 needs to control something in the Map, which is not actually it's parent component. Also, some data from Map needs to be passed down to Optionpanel1 so it would know what to control. To make matters worse, something in Options also needs to pass something down to Optionpanel1, so, even though event bus would allow communication upwards, it would not solve that I need to pass data from parents to indirect children and also components that are not it's children.
I can actually pass the required property down the line if I nest the Options inside Map and pass it down with :myProp="prop" and then in Options, declare it in props and bind to Optionpanel1, where it is again declared as a prop. But as I mentioned earlier, nesting elements that I do not want to be nested in a visual sense causes massive issues like mouse click falling through. Do elements even need to be nested inside eachother in order to define parent-child relationship?
I would want components to exchange read-only data without Y being a child of X in the DOM. Also, even if nesting components like this would not cause visual issues, does it not seem very annoying to have to register and bind it in every component along the way?
I don't understand why is it so difficult to simply read something from another component. It's starting to seem that Vue is causing a problem that it's supposed to solve? Am I missing something here or am I looking at this in a completely wrong way?
Thanks in advance.
Basically you have 2 options to control complex components:
Handle the actions in your so-called "smart component" (in terms of React), which is the common ancestor for the controlling and controlled components. It's a pretty good solution for small components, but that's not the case.
To separate common logic and data in a Vuex store. I'd recommend you doing this.
I'm working on an app that uses Vue. It is a kind of document editor that allows editing of content.
There's a filmstrip in a sidebar displaying the entirety of the document, and a viewport in the center displaying the current page/spread.
On large documents with 100+ pages, I'd like to throttle the number of updates allowed through to the filmstrip component as it gets a little laggy on resize and when the JS controlled layouts in pages all have to resize simultaneously when global fields are changed etc.
There's a data structure representing the document's content, which is rendered by Vue components in the viewport and the filmstrip.
I could maintain two data structures and only update the data structure used in the filmstrip 1000ms after the last user interaction.
However, it feels like there could be a better way.
Vue has a directive called v-once, which looks promising, however, I can't find out if that can be set conditionally.
If I could, then I could set a timeout on change, and clear it if a change occurs before the timeout ends, and then momentarily unset v-once, then on next tick, add it back on again so that rendering pauses.
If there's a way of doing this, I'd love to know.
Here Proposal: Allowing v-once to accept a boolean flag is very clear, you can't set v-once dynamically. Also there is an example of one way to combine v-if and v-once to achieve the result you want.
Excerpt from the link
v-once is used for static content. v-once tell the compiler don't add any responsive functionalities to save cpu time. Otherwise, if the content is responsive, no methods could be used to save this kind of cpu time.
Hope it helped
I have started to build apps with vuejs recently and have one small issue that I can't get around:
I am using vue-router to jump between pages and lets say I have a huge list where additional items may be injected with ajax, user has to scroll, he click on item, see the details (is in new route) and when gets back list is reinitialized and has to scroll again to be at the point he was previously. Do I have some possibility to keep the state of given component (and view like scroll position) while using vue-router or do I have to keep some cache-instance in main app component and then map it on init?
Thank you.
Essentially, the issue is that your component stores state internally. Navigating away clears the state. There are two ways I see this could be handled.
1) (quickfix) instead of redirecting use another way of displaying the item details (modal, or expand come to mind). This way the state of the component is not lost
2) (the "proper way") store the state. Inevitably, you'll come up against this sooner or later and the best way to deal with storing a state is vuex. https://vuex.vuejs.org/en/intro.html Initially, this will require a bit of learning and add some complexity, but it is a worthwhile investment
Protractor 1.7.0 has introduced a new feature: a new locator by.deepCss which helps to find elements within a shadow DOM.
Which use cases does it cover? When would you want to reach elements in the shadow DOM?
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
To answer your question, here's a related question: "what information does shadow dom provide that looking at raw html does not?"
The following snippet creates a shadom dom (view via chrome or firefox):
<input type="date">
If you click on the arrow, a pop up opens with all the dates, and you can select it.
Now imagine you are building a hotel reservation app and you made a custom shadow dom date picker, where it would black out (and not allow user to select) dates when rooms are unavailable.
Looking at the raw html, you see <input type="date">, and the value/dates that a user selected. However, how would you test that the black out UI is working as intended? For that you would need to examine the shadow dom, where the pop up resides.
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
Doesn't seem so in this website that shows an introduction to shadow DOM. It says that:
Shadow DOM separates content from presentation thereby eliminating naming conflicts and improving code expression.
Shadow DOM mainly helps with separating content to avoid naming conflicts and improving your code expression, making it neater and better (I assume). I am sorry to say that I don't actually use Selenium, so here is a website with plenty more information: http://webcomponents.org/polyfills/shadow-dom/
I hope this helps you!