I'm building a Gatsby site with Prismic that, as we're getting towards the end of the dev process, is starting to have a fairly large number of components.
I'm wondering, however, what the best practices are for components that are used in multiple places across the site although they might have different props or be accessing GraphQL queries differently? For example, I have a hero component that is used on multiple pages and templates.In one place it might be used in a Prismic slice, and in another, it might just be a part of a page, without slices.With that in mind, if I have a heading which would be templated in the slice's iteration using {slice.primary.heading.text}, and a heading outside of Prismic's slices templated using {document.heading.text} I'm, at this point, stuck creating multiple versions of the hero component, one for the slice and another to be used on pages.While I've had a good bit of experience with React and Gatsby over the last year, I'm still new to best practices.Is this the correct way to do it, using multiple components, or is there a better way to accomplish this?
Related
Imagine you are developing a big-scale nuxt app that has 100 routes. what is the best solution for managing routes (not micro-frontend) in this app?
What do you mean by this?
or should add all of them in pages directory?`
Here, we're talking about pages only, right? So /user/id, /post/id and so on?
If it's the case, you could have a /_entity/id or even a /_entity/_slug for more flexibility (with _entity being either user or post etc...).
If you have a lot of various pages like /about, /our-team, /careers and so on, I guess that those will need their own SEO, content and are totally legit.
I don't really see why this would be an issue at all. It will be properly organized, scalable and will not have too much abstraction neither (which is important IMO).
You could also export some of those pages into .md files thanks to nuxt/content and import them into the pages. Like the Nuxt documentation is doing.
If you really need to simplify those, yeah you could make the whole templates dynamic and generate the markup on fly. This could introduce some huge complexity that may not be needed IMO.
Also, layouts, slots and render functions can be a solution too I guess.
I'm not sure if micro-frontends (sounds like a buzz word for me) are actually several instances on Nuxt one next to another (sounds like a terrible idea if hosted under the same domain) or just "component-ization" of your non monolithic fullstack app (pretty much how we build websites for few years already).
But for me, if a project do have 100 pages, it is totally fine.
Of course, having some hardcoded /blog/post/1, /blog/post/2 is bad (lol) but a large app could be totally fine. It may create some issues regarding the build time and so on, but this is another subject and relies more of the way you do generate the project.
So yeah, if your interviewer wanted to go deeper than those approaches, you would need more details from him to exactly know what are the challenges and what could be used.
TLDR: as far as I know, no frameworks aim to reduce the number of pages because this is not an issue by itself. 10k Nuxt pages will not make your /about one slower by any means (if it does, the issue is elsewhere).
In team Vue.js project I'm curently working, I wrote something like this in view:
component01
component02
...
There is more than 10 componenets. In every component is one section of landing page, nothing fancy, mostly HTML/CSS and some animations, components don't have props and are used only once. Idea is to simplify maintenance of code - instead of editing view page with, for example, 1000 lines of code, we can edit component with 100 lines of code.
And got instructions to merge all components into one view (eg. 1000 or more lines of code). I'm OK with that, but got me thinking and searching for opinions.
Is there best practice for situations like this - use components even if there is no repeating and no props, to simplify code, or hold everything in one view (and long) file. Components can be in separate folders, so big number of components should not be a problem. Or will they?
Components are the building blocks of all modern JavaScript frameworks as they provide a better overall architecture for your application in terms of reusability, testability, maintainability and in the end SOLID and KISS principles.
I would recommend splitting your app in smaller and presentational components and use services for business logic. It does not matter if the application is small, by following these principles it will be able to grow with no or less pain. That is the way Angular encourages you to build applications.
As always in this industry, don't overuse these concepts and apply where appropriate and with common sense ;-)
This question is about possible higher-level approaches that one could take to applying version control to React components. Specifically, these components should be more on the "atomic" end of the spectrum, i.e. doing one thing powerfully in a variety of contexts.
Specifically, I'd like your thoughts on versioning such components at scale, whilst addressing issues such as:
Cross-project usability (i.e. <Button /> component in both of my React apps);
Theming (how themes and styles can be shared across these components); and
Dependencies (e.g. version 1.0.5 of <StackedButton /> depends on version 2.1.0 of <Button />)
I've been looking into Bitsrc.io as a possible tool to help me manage this. I've been largely addressing these issues by having quite a few (~10) Git repositories, each managing a loosely coupled set of components, e.g. text-components, layout-components, table-components, but I feel like I'm at a point, where with the number of components and the dependencies they have, further maintainability may be sacrificed if I make the wrong decision.
I've had some success using lerna; I think it might fit your needs pretty well. You basically would combine all 10 of your repositories in a single one, with each one now being a package within the repository.
Lot of advantages to this approach. Mainly, it lets you still have separate published packages, giving consuming apps flexibility on what they want/don't want to pull in, but it removes a lot of the overhead of having a lot of packages. It becomes much easier to make sweeping changes, and it's impossible for your packages to get out of sync, since they're always updated together. If you make a breaking change in one package that another package relies on, you would fix the package in the same PR as the breaking change.
I am trying to create a full page calender (All months are displayed one after the another in a single page). I am getting confused as to how to approach this, what I want to know is if making each day a component then a month component and the whole thing in a container bad? This code will go into production so I want good performance.
I also have to display some number(price for each date) with each date if that influences the decision.
I am looking to create a product that will look similar to React-Infinite-Calender but each day will also have a pricing detail as mentioned before.
Also is there a better way to approach this than the one I mentioned?
I don't think that modularizing your application is a bad idea or will affect your applications performance.
Splitting up an application in several components is what makes React this performant in the first place.
In your case it might be a good idea to determine if you need a component that is stateful or functional. From what you are presenting as your scenario I would go with an approach where the month (as one component) holds the state and then renders several functional components (as days) with the data (including the price tag you mentioned) passed to it via props.
There are several good ressources to be found online where you can read about structuring/modularizing your application with React components.
One of them is this post about structuring React apps: Structuring React apps
React is a component-based framework, so abstracting every item into separate component is the proper way. It allows you to have all the logic responsible for various elements incapsulated.
When creating your app, just remember to use map to generate the months and days inside. Doing to will quickly prove that your idea is correct.
Also, remember about passing props to children and stateless components, this will greatly improve your workflow and performance. Keep in mind though, that avoiding state can be harmful. Hoisting your logic up a few components will be a much bigger hit on your performance that using state.
Last, but not least, if you'll run into a problem with communication of components far from each other, try state management tools, like Redux.
I have to start by saying that I studied Angular 4 but I have not used it for any real projects and I don't know nothing about React. With so many technologies available I feel a little confused on when and how to use them. I have a website that I built using asp.net core. The website is a store that shows objects for sale and enable users to add and modify their products. The site is a MPA that eventually (not to say often) uses Ajax to make the application more dynamic and fast to load. I was thinking about turning the control panel that enables users add/modify their products, and uses a lot of javascript/jquery code to support those tasks, into SPA using React or Angular to make the website navigation more pleasant. Is this approach of using React and Angular in a section of website a good idea or Angular or React should only be used on the entire site?
Yes, you can combine React or Angular components with just regular website, especially when you want to rework complicated logic, which is better to do with such frameworks. You can also see how it works in action, reworking small components and decide if it worth.
I wouldn't say that it is a common practice, combining Angular 4 with React or the other way around. It is true that you can use React components in a Angular application but not the other way around.
Its really something you have to consider for yourself, usually you decide to take full advantage of a specific framework. Personal preference and or the preference of the people you are working with usually determine this.
All of this is very much based on ones own opinion.