I have a project where I will need to deploy multiple Nuxt websites, with each one using the same components. I don't want to have redundancy and having to change 10 times the same component in 10 differents projects.
So, do you have an idea of an ideal architecture and technologies to be used in order to create single Nuxt components that can be re-used within all the differents websites ?
I have read documentation about nuxt-custom-elements, would that be a possibility ? What are the down side, restriction and alternatives to this Module ?
Thanks you a lot for your help.
I am currently doing an analysis and research, I would love to hear from your experience with this kind of projects in order to not go into a wrong direction.
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).
This question already has answers here:
React Native + React (for web) seed project
(6 answers)
Closed 4 years ago.
For a project, we need to have a Website and a mobile App (not a responsive Website) that both will consume my API. I used to work with React so I've checked a lot about React-Native for the mobile App part.
As I may understand, this require to create 2 distincts projects and it seems more efficient to do so (furthermore if these 2 projects don't share the same client). The problem is that, at a first look, both will use the same store... I don't want to dupplicate my store neither update both of them each time I update my API... The only difference I see between my React Website and my React Native App is the way they render. They will both have same functionalities. Can we go further by hypothesis that they will also share the same containers?
I try to open an issue on the github but they redirect me here to discuss about it.
So I want to know if you guys have THE best solution (clean & without bad surprises) to share code between React and React Native? If so, a tutorial will be very appreciate.
(Note: Searches were very time-consuming, React Native documentation should reserve a section about this subject...)
This was answered in this thread.
The overall idea is to have different entrypoints for each platform, and have the platform specific code (React for web and React Native for mobile) share common code like the Redux store.
An in-depth article can also be found in the thread I linked.
That being said, there are a number of tradeoffs and pitfalls to this idea one of them being dependency management, as you can see by this comment from the linked article:
I've just learned the shortcoming of this structure. By sharing a common package.json between native and web, you've glued them together by their common dependencies, the most important one being react. Let's say you upgrade to a version of react-native that depends on >= react#16, but your web app depends on some other library which depends on =< react#15. This exact thing has just happened to me, and I'm not finding an easy way out.
Another viable approach would be to transform the common areas of code into libraries you can export and import them to each separate project (mobile and web). That way you avoid the problems with the first option, but now you still have to maintain and update two separate code repos.
To answer your question the comments: I don't think there's anything wrong with having one project sharing code for both platforms, but it has to be planned very carefully so you won't break both your projects when trying to add new things. Try to start by planning your project structure so there's clear separation between web and mobile code and check if your dependencies are compatible with one another.
Here's a blog post that has an example project that should help you with designing your project.
EDIT: You could try React Native Web, but that's still in alpha so I wouldn't recommend it for work related projects (should be ok for school/personal projects though).
i'm currently expolring ReactJS
i saw NextJS and React Router
Can anyone tell me what's the pro cons between the two. I'm not sure if it's right to compare the two, but from what i see, react-router already has SSR feature. So whats the benefit of using NextJS?
Thanks!
Next.js (see also alternatives like GatsbyJS and After.js) are full featured SSR/static site frameworks, so you get a lot of features out of the box if you need to generate a SSR static site. These frameworks have solved lots of problems, so adding a feature becomes as simple as reading the docs, rather than researching and coding on your own.
If you code your own setup with a standard React app and react-router then you might find yourself running into a lot of complexity and edge cases when you dig into SSR.
In short, if SSR is a core requirement definitely consider using a SSR React framework.
Jed's response sums it up pretty much, but here are some clarifications:
React router allows SSR, but does not implement it. You still need to make a server script that, at least, renders the app to a string and serve that to the client. You may need to do other things, like serve static files. NextJS does that for you.
SSR comes with a few caveats that NextJS also covers, mainly initial asynchronous functions (fetchs from APIs, for example). In a custom made system, you'll have to determine which functions you should call, usually based on the route, and pass the data to the components, usually with Redux
I'm currently working on webs with both systems, and both have some pros and cons.NextJS has a specific way to declare routes and a very different way of moving through them, but making a custom system that deals with everything that NextJS covers is quite the work. I would not recommend making everything yourself unless it's really needed, and maybe check alternatives like Gatsby if asynchronous loads aren't a concern
I have a problem with flux implementation on my app.
Heres the scenario:
We're a site builder plataform, we have pages where we don't know what will be rendering. Its completely dynamic, varying from user to user.
We have a lot of different components that may ou may not be loaded on the page and each component can have multiple instances.
What we need:
We need a FLUX structure that allows us to load only what we need from store and avoid unnecessary payload.
I have tried using Redux but the problems were:
Firstly we couldn't load all reducers at once but after a few research I built an interface capable of loading reducers on demand. But then I couldn't solve the problem with multiple instances from a component because the store file needs all states pre-refferenced :/
So, here's the question: How can I architect my app to use flux with dynamic pages and multiple instances from a component? Thanks in advance.
I think what you are trying to do is called "lazy loading". So you will just load components and pieces of javascript when they are needed.
Here you can find more information about (you need to generate more bundles of code with webpack):
https://blog.risingstack.com/react-js-best-practices-for-2016/
I will need this in a project in few months, but right now in our MVP we just need to make things run :)
Well, after a few (a lot) more research and attempts I'll implement a solution using React + Flux.Dispatcher + Backbone as suggested here:
https://www.toptal.com/front-end/simple-data-flow-in-react-applications-using-flux-and-backbone
===========================
Hope anyone has used that tip above. Worked nice for simple screens, got shit and slowly with complex pages.
Best way is to implement simple flux architecture as described in:
https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture
https://blog.risingstack.com/the-react-js-way-flux-architecture-with-immutable-js/
Connect your components with a store via decorator and go for it, works simple majestic.
Hope it's usefull for someone.
So my application is growing and becomming a fullscale enterprize application.
Because of this clients of my application has different request as to how it should look and feel.
Some of them want all of the content and some of them wants only parts of the content.
Because of these request we have to allow the users to costimize the application as they see fit.
Now ive been searching online to find a solution to how you might deal with this and i want to hear your opinion on the following:
The application contains the following features:
Chat
Forum
Usermanagement
Games
Now all of these features are used on different pages, some of the features are bound together to make 1 page an example of this might be:
Now the idea was to encapsulate all of these features into an angular module.
And each of the feature components into directives
using the above picture the game highscore would be a directive located in the GameModule.
Say for instance that our clients does not want to use the Game feature. Then all directives located in this module would not be visible / disabled.
Looking at the angular documentation this should be possible. But i need you guys opinion on this? Is is possible to do such a thing and if so how?
I hope you guys understand my question i really want to use best pratice to solve this issue and as far as i can read Modules is the best way of doing this.