I'm learning react. W3schools says (in this link):
The quickest way start learning React is to write React directly in your HTML files.
This way of using React can be OK for testing purposes, but for production you will need to set up a React environment.
So my question is : Why?
To avoid runtime react code compilation into Javascript which may consume lot of memory.
Your Browser do not understand React but JavaScript and when you are providing the babel to transpile your code, its not efficient and memory performant. So to make your app performant its advisable to create a bundle first and then deploy it to your webapp.
For learning purposes you can try developing an app by passing babel/react links and after sometimes you will surely feel that your browser starts hanging etc.
Related
We are rewriting an AngularJS app with svelte components and using Vite for building it.
It works great for the svelte components, but changes made to AngularJS code files requires the whole application to reload.
Has anyone solved that problem or and pointers that would help us construct the angularjs app differently in order to achieve that?
We changing pieces of it to Typescript, and import every file required. But the imports are not all referenced. Since AngularJS apps use injection.
Definitely not. AngularJS module unloading isn't a thing as it was never designed for that.
More information in this similar post: https://stackoverflow.com/a/23000380/4096074
I am still quite new to React, and I am currently working on a Django-React app. I read a bit about Next JS and it seems quite useful and interesting (especially for SEO), but I've heard various opinons about it. I am considering using it for the front end and rendering only.
Therefore I was wondering, would it be worth it to learn and implement NextJS (and re do some of the work I did with react), or is the effort to great for a minimal result? Will NextJS allow me to do more than react (in terms of SEO and rendering)? Does the complexity of a project really increases when implementing Nextjs + React-Django?
Lots of people are talking about NextJs and I was wondering if it was just "another framework" or really something more.
Have a good day
Nextjs is better for SEO as it renders server side and all the data can be indexed by search engines. IMO Nextjs is better because you are strictly using Javascript and it integrates very well with react. If you have good design patterns/reusable react components it will be very easy to integrate with Nextjs. The built in API feature is also very seemless. If you use Nextjs there is no need for Django.
I'm starting building a react native application for both iOS and Android. I've read through the documentation of react native application, but there is one thing now I do not understand:
Is react-native app fully native application?
They say in react-native, that it would be. Then why am I asking this question? Well, I found the reason to ask the question through https://github.com/Microsoft/react-native-code-push. According to code push, they are able to dynamically update the application. And this is done by updating the javascript part of the application. But wait, if the application is real native app, then in the final version of the app there shouldn't be any javascript, am I right? So how are they doing it? Are they compiling the application at code push servers, and then sending the compiled app to the user or what? This really worries me that the react-native app is really not fully native app.
The CodePush plugin helps get product improvements in front of your end users instantly, by keeping your JavaScript and images synchronized with updates you release to the CodePush server. This way, your app gets the benefits of an offline mobile experience, as well as the "web-like" agility of side-loading updates as soon as they are available. It's a win-win!
Also, the reason I'm doubting this is because they say also in code-push documentation, that they are unable to update the native part of the react-native application:
Note: Any product changes which touch native code (e.g. modifying your AppDelegate.m/MainActivity.java file, adding a new plugin) cannot be distributed via CodePush, and therefore, must be updated via the appropriate store(s).
If the react-native app would be fully native, then in the end, all code should be native code. So I don't really understand why would it be harder to update the native native code, than the code that has been compiled to native?
If you change only code in /src/ folder (JS code) and without adding native modules
you can use CodePush to update your application.
If you change code in /src/ folder (JS code) and add some natives modules, you can't use CodePush to update your application.
You're JS code is compiled and read by native components. That's why you can update the JS layer.
If you take a look into your .ipa file and open main.jsbundle (unminify required) you can see your JS code. example:
I have an app based on the create-react-app starter kit and need to switch to universal/server rendering due to SEO issues.
Is there an easy way or example of taking the create-react-app teamplate and adding or modifying it to support universal rendering?
A lot of the examples I see for universal are overly complex for my needs and I prefer to keep it very clean and simple, if possible.
Thanks.
EDIT: FYI,
I found this medium post which points at this repository.
Seems simple enough, but since I'm a newbie on all webpack/react/node related stuff, if anyone thinks it's the wrong approach, would love to know...
There was a proof of concept of adding server rendering in this PR.
I can’t speak to how good it is but it’s something you could start with.
You may also look at some of the alternatives.
A few of them provide server rendering out of the box.
I've just created react universal (server-side rendering) starter used recommendations from redux and react-router v4. Fill free for feedback
https://github.com/gzoreslav/react-redux-saga-universal-application
You can take your app (bootstrapped with Create React App) to the next level by replacing react-scripts with a slightly altered version - react-app-tools, which allows adding server-side code to your project (e.g. for server-side rendering purposes and/or implementing an API endpoint). It will allow compiling and running your app using normal Create React App pipeline, using a single instance of Webpack, on the same HTTP port.
You can find more info by visiting React App SDK.
Pardon my English, it is a second language. The whole point of an isomorphic app, as opposed to a regular client-side SPA is so the client doesn't have to download the whole JS file initially which results in really slow initial load time.
I've been trying to teach myself server-side rendered React, and after watching countless videos around the concept and following countless tutorials on the actual implementation, I still can't get my head around this (at least this is how I understand it):
Despite the server conditionally rendering pages and sending props to the client on url change, the client side still uses a router that includes all the entry points for the app (by requiring all of them, and then loading the file based on the url location). Doesn't that means all the files are included in the main client JS file anyways since it's already been required by the client-side router? Doesn't that defeat the whole purpose of server-rendered React? Or am I thinking about this the wrong way?
In short, how does an isomorphic React app really works with a client-side router that includes (by requiring them) all of the app's entry points?
I'm not sure that "The whole point of an isomorphic app [...] is so the client doesn't have to download the whole JS file initially which results in really slow initial load time" is necessarily true. I think the primary reason people do this is for SEO reasons and to improve perceived load time. You still get the benefit of showing the users the page before they have to load all the JavaScript (e.g. yes, they have to load all the JS, but it's OK because they already have most/all of the content). The app upgrades to an SPA transparently, providing a seamless experience for the user.
That said, you can implement a system where you don't have to load all the JS at once with something like webpack's code splitting. There's even a simple React Router example that does this.