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.
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 3 days ago.
Improve this question
I'm currently building a website in Next.js and I've gotten to the Blog page which got me thinking about how to handle this page but also whether or not I should approach the rest of the pages differently too. I am just hard-coding all the content (text and images) and I was wondering if there is a better/smarter way to do this? Or should I keep going like this and also hardcode blog posts into my website.
I'm not that experienced so I wouldn't really know how this affects performance or other aspects.
Better or smarter way is very subjective in my opinion. But I will give you some options:
Hardcode it just like the way you do right now. It won't affect performance but you will have to write the code, push it to some version control (if you use one), trigger the build, and make sure it works.
Use Markdown file for every post and have next.js automatically build routes of it. See this tutorial if you wanna take a look. The pros are it's simple (doesn't need a database), and you don't have to write the entire code -- just write the content in a markdown syntax. But you still need to push your changes and trigger the build.
Use headless CMS like Strapi, etc. Personally this is the most convenience way. Write your content, click that Save button, and you're done. But it needs more setup then the other options.
Create your own backend and database setup.
Hope it helps.
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 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 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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Im just begining to use polymer and i was testing to make a demo website using polymer components but i felt difficulty on making the pages responsive ?
Should i use css?
Thanks
Yep, you could use CSS. However, web components can be a bit tricky to get responsive because of their nature of re-use and possibly different locations.
Unfortunately, while CSS/media-queries are one solution, it's not the perfect solution. Why? Because the same component, depending on it's location/container may be desired to look/behave differently. For instance, a "voting" component in a primary content section (800PX wide) may display additional information vs the same component in a right rail (200PX wide) where just the question/answers may be displayed.
What we as web developers really need are "element queries", which allow components to react based on their occupying space (rather than the page-level layout). There are articles and polyfills regarding this that may be of interest to you. One can be found here:
http://www.smashingmagazine.com/2013/06/25/media-queries-are-not-the-answer-element-query-polyfill/
IMO, you should focus on Web instead of Mobile, because the native Android browsers before Android 4.4 doesn't support Polymer, even with Polyfills!
Anyway there is a core-drawer-panel, which is a responsive layout you can start with.
https://www.polymer-project.org/docs/elements/core-elements.html#core-drawer-panel