The app has 2 levels of users, a regular user and an admin. You need to make a header component in which some information is the same for everyone, and some - only for admins.
There is a basic header component :
<div class="user-header>
<img src="logo">
<div class="user-header__links>"
...
</div>
</div>
'user-header__links' contains links, some of which should only be shown to admins. Also, the header must still have dropdown, that is available only to admins.
I see 3 possible solutions:
Make 2 different components, i.e. I have UserHeader for the user, and copy this code to a new component, edit as necessary and get AdminHeader, adding the necessary elements and links
in UserHeader, make props / slots for throwing additional content into it, and then adminHeader will look something like this :
<UserHeader links={some additional links for admins}>
<AdminDropdown/>
</UserHeader/>
Leave only AppHeader component and put elements in it for both users and admins, and just check the "admin" elements and show them if the user is also an admin.
I understand that in principle all the options are working, but to come to an understanding of which option is more convenient and practical somehow does not work. Also, if there are any articles regarding these points, I will be grateful for the links.
I'd say that the option 1 is just lots of unnecessary boilerplate, but only you can choose between 2 and 3, as it all depends on your proj structure, implementations and so on...
As with everything, app architecture is a lot about taste... I, personally, very much like the idea of "minimalism" here.
I think Conditional Rendering would help you solve this problem - here's React's doc page for it: https://reactjs.org/docs/conditional-rendering.html
Related
I need to implement components tree on React.
And I'm wondering what is good enough pattern how to break everything in tree
but with scaling(code or team) in mind.
Usually I'm using next way:
function UserAvatar(props) {
return <div><img src="" alt="" /></div>
}
function UserEmail(props) {
return <div>e-mail: some#email.com</div>
}
function UserSection(props) {
return (
<div className="container">
<div className="section">
<UserAvatar />
</div>
<div className="section">
<UserEmail />
</div>
</div>
);
}
But should I avoid all this layout divs and make layout cleaner?
One obvious option is to move into the separate component layout stuff.
Thanks
Guidelines on breaking down components:
When your component is doing too much. Components should ideally be focused on doing one (or a few, but not many) things. The most obvious sign is when the number of lines in the code is getting too long. As a rough estimate, components should not be more than 300 lines.
When you want to reuse components across multiple parent components, you'll have to break them up.
If you want to optimize the render() of specific subtrees of a componant via shouldComponentUpdate(), then you have to break them up as you can only implement shouldComponentUpdate() on the component-level.
Separating data fetching logic from rendering and handling user interactions logic. Instead of making one component do both data fetching and (rendering and handling user interactions), break them down into smaller components so that you can test the components separately:
Test that the first component fetches data.
Test that the second component renders the data properly and can respond to user interactions.
Read more about it here
Many more good answers by Kent C. Dodds here.
It's a good practice to keep each Component in their own files then import them where you need to reference them.
Also, in your example it's most likely you'll need to set the avatar url and email as props. Then make the UserAvatar and UserEmail render the values. Also, it's good practice to setup the propTypes, so other developers (and yourself) know which props to pass.
One criteria to break down components into subcomponents it's when they deal with different concerns, or when the file size is getting too large. Another criteria is when you need to re-use that component in some other context.
Hope this helps.
I noticed on youtube that replies to each comment are inside a <div id="replies">. So the same id is used for every comment reply group.
When is it a good practice to give same ids to multiple similar elements?
I know ids should be unique, that's why I'm wondering about this.
To check it, go to a youtube video, inspect and select the reply area of a comment. Optionally, Ctrl+F in inspect and search replies.
YouTube uses web components which might be the reason there are multiple of the same IDs. Web components are encapsulated chunks of HTML, javascript, and CSS that you can drop into your pages. You can read more about them here: https://www.polymer-project.org/
So my thinking of why YouTube specifically has multiple of the same ID is that the replies component itself has an ID of replies and is being targeted on a component level rather than a global.
I hope this makes sense? Even if it doesn't, try to avoid ID's that aren't unique like the others mentioned.
One of the reason YouTube can have duplicate IDs, completely invalid looking html and still get away with it, it's because they are generating dynamic content. Remember, even though it is incorrect, the browser will render it just fine. They are not using the ID to mark a unique element, but more as metadata.
Note that Youtube uses custom html tags that I assume helps them reuse code for not just the website, but also for their app.
Read more about custom elements
Update: Just wanted to show an example on how generating content through an application can help you get away with things that could otherwise be a problem.
Writing Inline css is not recommended mainly because it becomes impossible to maintain the larger the css becomes. However, you can code it in an external file during development, then compile it to be inline using an application and have none of the headaches.
See example
I'm using Vue.js to build ui for my html5 game. I have a case where I want to define ui-containers which essentially just group other ui-components and position them to somewhere on screen. So I could have something like this going on:
<ui-container>
<ui-component1></ui-component1>
<ui-component2></ui-component2>
<ui-component3></ui-component3>
</ui-container>
Where I need to add and remove those components dynamically based on data-model which represents the content of the container. The problem is that I'd like to keep ui-container generic, so that I can append any Vue-component to it without having information in template about which components there might be.
I googled and found this example which concerns injecting components dynamically: http://forum.vuejs.org/topic/349/injecting-components-to-the-dom
While the data-driven version in example was easy to make and understand, it uses v-for for tag and therefore requires one to know before hand the type of child-component.
So question is, how I can generalize that example to work with any component dynamically? Should my data-model have the type of component or tag name of it and then interpolate it in v-for? Or is there existing mechanism for this kind of requirement?
You can use special is attribute to dynamically set the type of a component. Here are the docs. The code will look somewhat like:
<div id="app">
<div v-for="component in components" :is="component.type" :value="component.value"></div>
</div>
Working fiddle to play with: Dynamic Vue.js components
In order to navigate through the elements/components hierarchy of EXTJS , I need to see what is up and what is down from any point like an element. Too often I go the wrong way and it takes me hours to figure out the path of a component/element (from to). Opening up the debugger and doing it through dom is abominable. Is there a nice utility or way in EXTJS to xray view the hierarchy in some way? And if you are sure that there is not, please let me know how you do it.
Let's say I start this way:
var panel = Ext.ComponentQuery.query('panel[itemId=dateOfDeathPanel]')[0];
And I need to get to a textfield or button, what is the pro's way of navigating the hierarchy, other than opening up the files and wasting precious time deducing how the components/elements are arrayed?
Many thanks for your help.
DK
Well, this question is quite big and not easy to answer because it depends on the architecture / pattern you choose as well, mvc, mvvm, etc..
I really like to use viewcontrollers to access the components using the reference config object or itemId, described here:
http://docs.sencha.com/extjs/6.0/application_architecture/view_controllers.html
Beside that you can install in Chrome the AppInspector plugin from Senchalabs, this can help you navigating through the component tree, stores and more.
Repo:
https://github.com/senchalabs/AppInspector/
Chrome store:
https://chrome.google.com/webstore/detail/app-inspector-for-sencha/pbeapidedgdpniokbedbfbaacglkceae
Can you use beside that the .up and .down selector in extjs:
extjs using up and down methods
I have a huge form divided into sections. It has about eight sections and it will simply be unwieldy to put this giant form on one page. No one would ever slog through it.
I also decided that dividing it into pages will also not be ideal because if someone is section 6 and realizes he needs to change something on section 2.
I created a client side solution using Jquery. So You just click tabs representing sections of the form. So you hide a previous section section when you click on a new section and handle all the logic of saving server side making sure someone can switch back and forth while validating data on each section. Behind the scenes its still one huge form. A lot of Jquery is used to make it work properly. It is tightly coupled to the DOM and no one can understand the code unless I explain.
Also when making changes you have to make sure there are no lingering events which cause something unexpected to affect another section of the code.
Its quickly becoming a monster. I think this is an ideal problem a Javascript framework would solve but I have no idea where to start. How would it fit in the context of Javascript MVC especially all the DOM manipulation and event driven approach I use. any ideas or suggestions are welcome.
I would consider using AngularJS
This is a real war story - I was struggling with the exact same issue you are. Huge unwieldy form, needed it to be refactored into re-usable components(since one portion of the form included a pricing page).
Getting started is pretty easy, I'd suggest to look at the tutorial before you see my solution.
Here's how I solved my issue -
Have one controller for your form.
Use UI-router for making sub-routes of your form (e.g. /signup/profile, /signup/address etc); all of them being controlled by your main controller. Store them in separate HTML files as templates being rendered on a view (yay!)
Also, you don't need a major commitment to use angular, you can just use it for this purpose in your app.
Hope this helps.
Frameworks that handle data binding and embedded control statements sound like they would be ideal for an issue like this, like Knockout.js or Angular.js.
For example, with knockout, you could have a segment like:
<div data-bind="if: someCondition">
Only show this section of the form if the condition is met
....
</div>