Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

template performance problems #23

Open
alexsandr1992 opened this issue Jul 21, 2020 · 3 comments
Open

template performance problems #23

alexsandr1992 opened this issue Jul 21, 2020 · 3 comments
Labels
feature request New feature or request need more info Further information is requested

Comments

@alexsandr1992
Copy link

Hi,

First, I must say that your template helped me a lot in beggining development on .Net Core + React. Thanks.

But technologies is in progress and I have some questions for this template development:

  1. Temlate not use react-script. Many developers consider that this package more productive. Is its implementation planned?
  2. Your server-side require double rendering if use async request. As I known this problem not have solution.
  3. Redux state write in HTML that leads to an increase file and low productive. This problem have solution?
@alexsandr1992 alexsandr1992 changed the title template problems template performance problems Jul 21, 2020
@NickMaev
Copy link
Owner

NickMaev commented Jul 21, 2020

  1. Temlate not use react-script. Many developers consider that this package more productive. Is its implementation planned?

That's interesting. I will consider that point.

  1. Your server-side require double rendering if use async request. As I known this problem not have solution.

Could you provide an example?

  1. Redux state write in HTML that leads to an increase file and low productive. This problem have solution?

I don't think so. But will be considered.
Could you provide some metrics please?

@NickMaev NickMaev added feature request New feature or request need more info Further information is requested labels Jul 21, 2020
@alexsandr1992
Copy link
Author

  1. Your server-side require double rendering if use async request. As I known this problem not have solution.
    Could you provide an example?

It follows from these lines of file boot-server.tsx:

 83: renderApp();
  ...
 95: // Once any async tasks are done, we can perform the final render.
     // We also send the redux store state, so the client can continue execution where the server left off.
        params.domainTasks.then(() => {

            resolve({
                html: renderApp(),
                ...
            });
  1. Redux state write in HTML that leads to an increase file and low productive. This problem have solution?
    Could you provide some metrics please?

It depends on how widely the Redux store is used in the project. If widely then converting a large repository to JSON string can be comparable to the other HTML

@XuHaoJun
Copy link
Contributor

  1. Your server-side require double rendering if use async request. As I known this problem not have solution.

the first render is collect tasks from component's constructor, but we do'nt need to travel all node for collect tasks on most use cases(only on entry PageComponents).

  1. custom a renderer by react-reconciler and partial render PageComponents.
  2. add a store like serverEnvStore with {readyFirstRenderOnServer: false} state and set true before first render on server-side and render nothing on PageComponent.
  1. Redux state write in HTML that leads to an increase file and low productive. This problem have solution?

i guess you want fast ssr for first loading and get reduxState later.

  1. put your reduxInitialState to body end and before scripts, that a little improve first visual loading.
  2. drop state in server-side and get state in client-side before call ReactDOM.hydrate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request need more info Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants