I'm building an application that is using NextJS to handle stuff that should be SSRed like landing, FAQ, blog pages. I also have an API for the application itself to interact with. Emphasis on application, since the pages NextJS is rendering isn't necessarily the actual application.
My question is would it be ideal to set up Webpack, Babel, etc for the actual application since it would be a gated application resulting in it not benefiting from being SSRed like the front-facing pages?
Related
I have a request from a client to implement deep linking in our React application whereby clicking a link will take them directly into the installed app (potentially to a certain point but not sure on that yet).
To my understanding react-native and react-navigation both handle this as part of a feature set within "Linking" that they offer. However it seems excessive to import a framework just for deep linking (perhaps not though).
After googling I can only really find references to deep linking on react-native or react-navigation.
What is my best course of action?
Let's get to some basics first, then it will be clear.
In modern SPA's, say with React, it's common for the SPA to handle navigation itself. You need to use browser's history API. It's because your SPA is just a single index.html with bunch of js code, so it sort of virtual, every page is constructed by your app. In order to not reinvent a wheel, its easier to use some library for that, say react-router-dom.
But then everything works as expected, and you have deployed your app. When user wants to get some deep page, say, https://my-awesome-app.com/deep/page/1, browser will just send a request to a server, asking: "Please, server, give me a page 1.html, in folder page, in folder deep". But server doesn't have that file, because it has literally one index.html, because its a SPA application. Then we need to tell the server to re-write all deep routes to index html, here is an example for my app hosted on Netlify:
[[redirects]]
from = "/*"
to = "/index.html"
status = 200
When user will ask for that page, server will 'redirect' that request to the index.html and my react-router-dom will figure out which 'PageComponent' to render based on that path.
So, you can implement routing in your app yourself, probably using browser's History API, but I guess it might be easier to use library. But it's your call.
On the other hand if your app is not an SPA, the story might be different, because say in NextJS routing is implemented in framework itself, and if used deep linking would require different setup depending on how app is deployed.
Deep-linking is handled largely by Apple and Google server-side
https://www.adjust.com/blog/dive-into-deeplinking/
React-native provides extended functionality for deep-linking within mobile apps but normal web-applications there is no need to implement it there. Use universal links or Google specific links as standard linking within your web app to enable deep linking
I'm looking into building a very simple CRUD web application fetching data from and sending data to a RESTful API backend.
Since I have a good experience with Gatsby JS and most of the features it ships are very useful, would you recommend using it instead of the more vanilla create-react-app? Are there any drawbacks that I should know of?
I've been searching the web for info and showcases but there's not much around on the topic of Gatsby JS used for web apps.
Thanks a lot.
That depends on requirements to your application. If you need static rendered pages, Gatsby JS is ok. If your application is not needed it, but you need any server side live rendering, maybe you should look on something like nextjs. If it doesn't require anything of that, using of Gatsby may be overwhelmed and unnecessary and create-react-app will be enough.
In an article I read that
React uses server-side rendering.
But in another articles I came across this:
Client-Side-Rendering is a relatively new approach to rendering
websites, and it didn't really become popular until JavaScript
libraries started incorporating it into their style of development.
Some notable examples are Vue.js and React.js
Now Which statement is correct?
When I use create-react-app and run npm start, it seems to me that React uses the Client-Side-Rendering. isn't it?
It’s client side. But React, like some other client side libraries, can be used on the server to prerender it with node, usually for SEO.
Out of the box it renders on the client side.
But, if you have a requirement to render pages on a server, you can achieve this with:
Next.js or
Hypernova or any other tool (there is a bunch of them nowadays!)
Note, that SSR will require a bit more experience than a regular React app.
The main goal of this approach is to allow search engine robots crawl information form web pages(SEO).
create-react-app uses client side rendering by default. There are some tools like next js and gatsby js which pre-render pages on the server side. You can also do Server Side Rendering from scratch.
A few years on from the last answer, it is now quite difficult to implement a client-only React app - serving it on Node is trivial and absolutely what it expects, trying to use it as a client library with other server-side support is more of a challenge and documentation about how to do this is patchy and much of it out of date.
I watched Google's conference on SEO and they suggested to use Dynamic Rendering for JS built applications (React, Vue, etc). One of the tools to achieve this is with Puppeteer JS.
I need to create an app that relies heavily on SEO so Server Side Rendering (SSR) is extremely important.
I know that Next JS by default accomplishes SSR, but can I do the same with Puppeteer + Create React App? What is the difference between Next JS and Puppeteer in terms of SSR and Dynamic Rendering, and which one is better for SSR?
In short,
Next.js is a node framework. You use it to write code, i.e. build your application.
Pupetteer can be considered a tool. It comes bundles with Chromium which is practically a browsers equivalent to a testing environment. You writes tests via pupetteer to run scenarios in chromium.
I've provided an over-simplified explanation for those who want it. Shmotam gave a brilliant answer if you want depth.
Difference Between Nextjs and Puppeteer JS is very very simple.
Next Js :- It is React Framework for server side rendering those help in SEO, Optimized for Discovery , Lightning Fast Delivery.so ,very simple word is SSR. For Link https://nextjs.org/#features
Puppeteer JS it is Developed by Google and this is used for End to End testing of your application like selenium.
Both are completely Different and purpose are also different.
Headless Chrome enables "isomorphic JS" between server and client. It's a great option if your library doesn't work on the server (Node). Example for it is lit-html which it's core feature doesn't work outside the browser.
The difference is huge in terms of features.
Next.js offers some nice features that Pupeteer doesn't.
Hot reloading client & server
Automatic code splitting
Built-in CSS support, CSS-in-JS
Fetching data and component lifecycle
and more.
Some feature of Pupeteer:
Generate screenshots and PDFs of pages.
Crawl a SPA and generate pre-rendered content (i.e. "SSR").
Automate form submission, UI testing, keyboard input, etc.
Create an up-to-date, automated testing environment. Run your tests directly in the latest version of Chrome using the latest JavaScript and browser features.
Capture a timeline trace of your site to help diagnose performance issues.
and SSR apparently...
So you can see the major difference these two tools have.
Next.js is opinionated but aims to do SSR with react and builds on that concept;
Take into account that SSR with Puperteer in relatively new whereas community adoption of next.js is already mature with nice set of examples with different tech stacks.
nextjs is the powerful framework that supports ssr (server side rendering) and seo friendly Google search engine.
The react of interpretation is that the component is called after each state change. but nextjs load component and call getInitalProps first time, so view page source you can see data loaded
Puppeteer is used to make bots which works at backend.
NextJs is used to build Full Stack Website. And may be it will soon be available for React Native to make mobile apps.
When creating an app with create-react-app,there is only one index.html,does that means React can only handle one SPA at a time? What if I want to develop multiple pages? Should I create another SPA with create-react-app and then put them together after building each of them?
Update:
Parceljs can do that. here is docs.
You can use Parcel instead of Webpack (which being used in create-react-app) and it provide you zero config environment to develop web apps (using react or anything else).
Having multiple pages (instead of SPA) is not what most React environments had in mind [before - see update above].
You can have different page URL's using react-router or similar client side routing solutions.
If the concern is bundle size, there are solutions using webpack or parcel to lazy load each bundle whenever they needed or cache bundle (using service workers) and so on (Tree shaking, ...). (check Code Splitting in React Docs)
Other concern I might have in my brain is SEO, in this case you may find Isomorphic app (react server side rendering) useful which initialize first view of requested URL HTML and sends it to client, then client will load react and react will take control of UI. This will help Google (or other search engines) find your URLs fast and user experience in transitions between pages will remain seamless.