Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
From a maintenance/architecture/performance perspective, when writing a react application, is it better to put all components in a super/parent component and bind it once to a page, or to have multiple mount nodes on the page for each piece of functionality?
My current approach is to have multiple mount nodes on the page so I can have a more flexible design. Basically like a bunch of 'component boxes' in different parts of the page, that way I can easily move an entire box to another part of the page and everything still works the same without being dependent on each other.
Is there a "best practice" for this (in terms of future maintenance), or has react not been around long enough to establish such a thing?
The most common practice I've seen is a single mount point for a the main react render. This has a few advantages
Keeps the HTML minimal and simple, this reduces potential confusion about what's handled by the DOM/HTML and what's handled by React/JSX.
Reduces the interface boundary between the root HTML and React. Fewer places where props need to be passed from outside React.
Simplifies the reasoning about what happens when. For example it can sometimes be tricky to determine when React applications are done rendering. Having multiple render operations makes this more difficult.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
When we have component to write all logic then why we use redux. As we can separate template and styling from component
In the simplest words, you need redux for very complex state management in a large project. When you work on a large production level project, there are several components and states to worry about, and passing components between states becomes a mess. You could use context but in many cases you may need to move state up by 1 or more components to be able to use it effectively. This kind of problem is what redux aims to solve, and you will not be able to appreciate unless you work on a large project where components depend on other component's states.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have found some components that are not updated with the last React version, however, those components work. But I was wondering if those components are not updated would be the best option or a good practice to try to implement the libraries in React without the npm packages?
Thanks.
I'm my experience, it'll depend upon the product you're working on. IE. you're working in a UI that is not likely changing and once it's done, it'll remain the same for some time (rare case), and it's not too complex. I'd go for the component even if it's not that updated.
If the benefits from constructing the component yourself (long term maintainability, extensibility, etc.) are important to your project and it won't take that much time, maybe it'll be the best option.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am new to React and was learning what component is and what should be considered as component. As I found out component is considered as a certain block of a web page that can be reused and I hope I am right with this statement. But as you can see in the picture below button "What should I do" and add caption with input box together are considered as components. Why? those buttons are not reused anywhere in the same page so why should they be components. As far as I know, Component is a block that is reused in the same page several times
Flexibility.
If you particularly style your button one way and it takes a lot of copy-paste to use it elsewhere, why not make it a component and just call it.
Alternatively if it's fairly simple, you can just write it as is and move on instead of going through the overhead of making it a component.
It's entirely up to you.
Don't take the re-usability aspect too serious. Think of components as parts of a machine. You can order a motherboard, screen, mouse, keyboard... for a computer, or you can order the laptop as a whole. Up to you.
This really depends on you. The idea is to make as much reusable components as possible in React, if you stick to this formula your life will not only be easier but also your project will look clean and proper.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need to implement a SPA whose components are going to interact with their local state and are minimum the cases in which these state is going to be nedded by other components. For example: the employee component contains state about an employee that only will be shared with the employee's component children but not from other different component in the site. Until now my idea is to create 'stores' in the parent component (Employee for example) implemented with hooks and Context Api, for achieving max development speed and clarity in code. What do you think?
This is ultimately subjective, and it sounds like you're already leaning towards using the Context API. We made a similar decision on our current project; the amount of data that needs to be shared across the application is quite small, so adding the additional code, dependencies and file structures for Redux did not seem worth it.
But if you are using Context, make sure you have thoroughly plotted out the data flow of all parts of your application, as it's easy to overlook something and run into a situation where getting the data outside of a particular module can become very difficult. Also consider its size. If it's a large application, the benefits of centralizing your state changes for easy testing and debugging are not negligible, and Redux can also help boost performance by automatically memoizing connected components.
Again, this is ultimately opinion-based, but I think it's a concrete and common enough concern with React apps that it bears some discussion, though this might end up being closed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Since Backbone's Router only work with "#", it means that it should be all in the same page. Should a BB application be only in one page and have only 1 Router?
One of the many nice things about Backbone is that it is very unopinionated about how you work with it. For example, if you just want to use views, then you can do that, and if you want to just use models, you can do that as well.
A Backbone application can be a single-page application, and it certainly provides a lot of functionality to make that easier if that is your goal, but it doesn't have to be. There is absolutely nothing wrong with explicitly calling your views by hand instead of using a router.
To answer the second part of your question... No, you can have as many routers as you like. However, I'd say a large portion of Backbone apps out there make do with just one. I am working on a Backbone app that has over a hundred different views, and I've never run into an issue where I'd have to introduce a secondary router.
Finally, a bit of a correction on your end; The Router object actually doesn't enforce the "#" anymore as long as your browser has pushState functionality. Older browsers (mainly IE) will fallback to the hashtag approach if necessary.
Hope this helps!