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 :)
Related
I get all the concept of components but one thing I am stuck at is - when to create a component? In other words, what part of the page should be a component?
Link to sample problem image
Taking above image as example, what I think is progress bar can be one component and form, quotes list, blue alert can be second component.
Please advise as necessary.
There can be many reasons for creating components, such as when you need to create a reusable element, splitting the code to make it easier to understand and reduce code complexity.
In your case 1. you can put both of the sections into a single component or you can put them into separate components if you want to reuse them somewhere. 2. if your code is too much and you want to make it simpler to understand in that case you can also create separate components.
I have strange (at least to me) problem with multiple checkboxes with v-model. When using multiple checkboxes that are v-model'ed to one property then normal array is produced which is done with code below:
.form-check
input.form-check-input(type=“checkbox” name=“checkbox” v-model=“methodology” value=“issue tracking tool”)
label.form-check-label issue tracking tool
However, when I try to move it to Single File Component I had to copy some magical tricks from Vue.js forum to make it work. I still suspect that there must be easier way to achieve it. I can’t imagine that it wasn’t solved with simple solutions since it’s quite a common pattern (checkbox in a component - nothing exotic, right?). Any help appreciated!
Here is the working jsfiddle - please have in mind that there is no errors. I just want to know if that really has to be that complicated.
The answer is, no. You may be able to do this magic differently, but it needs to be done.
Vue has to do magic behind the scenes for checkbox because unlike all the other inputs, which have a single item that gets updated, the checkbox has to manage whether the a value is in an array. This means that the listeners and values have to be patched between the wrapper and input.
Here is my problem:
I typically have a paginated datagrid with a lot of rows. I want to be able to edit the data for each row of course but I have 2 constraints on this:
I need the edition form to replace the content of the page (I don't want a popup, modal dialog or side panel)
I don't want to lose the state of the datagrid: maybe I navigated down 5 pages in the datagrid and I don't want to be reloaded on the first page. And actually, I'd rather not reload the data I already had (the edited data will be updated automatically by my persistence layer anyway).
Ideally, I would have liked to have some kind of subrouter but I'm not sure how it would fit the first requirement. Otherwise, I could have a component that would be hidden by default and positions itself on top of the datagrid view when necessary but that feels quite hacky and forces me to have everything in the same template. And I will have to handle a stack of these components if I have several different 'full-screen panel'...
Any idea on a correct way to implement this?
Thanks!
I tried different solutions to no avail unfortunately. I had a long discussion with #Kukks on gitter and we agreed that using subrouters and viewports might be a bit overkill for my use case.
I reverted to my original idea of using absolutely positioned components to hide the previous one in a kind of "deck layout". This is not ideal as I would have liked completely separated views and using components forces me to declare them in the main view but it works well and is very easy to implement...
So: not as clean as I would have liked but much easier to implement and less convoluted.
Consider using Router View Ports
http://aurelia.io/hub.html#/doc/article/aurelia/router/latest/router-configuration/9
I am using Template10 with the Hamburger starting project template. I'd like to have a margin between the hamburger area on the left and all content. I tried changing the shared Shell.xaml page (by adding a margin, etc.) but couldn't figure out the best way to sort it out. Conceptually, that makes sense, but it's the specific detail of how to make it work that I'm missing.
Is there an easy way to do it without changing each content page?
Regarding the questions in the comments: I want it in the closed case of a wide view; the question doesn't make any sense in any other case. As far as what I tried, it doesn't really ultimately matter, since none of what I tried worked - I'm asking what the right way is to do it, which I never figured out.
Here's what the default looks like, without a margin:
Here's what it looks like with a margin added to the content area, which is also how the sample template contents handle this:
I don't want to have to mark up every content page with left margins to get the offset in the second picture.
1: https://i.stack.imgur.com/jUIuO.png
Okay, now I have enough information. You have a few options here. The first is just bite the bullet like the rest of the developer community and format your pages like normal. But if you simply must, you can create an implicit Page style with a setter setting Margin="16,16,16,16" but, listen, and I am not kidding, you will ultimately regret it unless your app is super-simple. The biggest problem will be the spacing will be OUTSIDE the containing ScrollViewer.
Thanks for using Template 10.
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!