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

If Fresh /components/ folder doesn't return JS, should I even bother with memo()? #2433

Closed
saeho opened this issue May 17, 2024 · 4 comments
Closed
Labels

Comments

@saeho
Copy link

saeho commented May 17, 2024

I understand that everything in /components/ are basically html and only served as such to the client without any javascript.

If that's the case, should I even bother wrapping the functions into a memo(..) in any files in the /components/ folder?

If islands' javascript code works, then that means data will change and pass down to components in /components/ files. But if they are html, and not javascript, does it matter?

Should all /components/ be written in pure functions? Should memo() ever be used except islands?

Please advise.

@marvinhagemeister
Copy link
Collaborator

In 99% of cases you don't need memo(), even in React land. You only need it when you notice a performance problem that you are 100% sure is caused by rendering a component unnecessarily.

With Fresh's islands architecture this is even more rare as most components are only rendered once on the server. This makes memo() useless as it can only help when the exact same component instance is rendered multiple times. This never happens on the server.

The only scenario where it could theoretically matter (in 99% of cases it doesn't) is with islands or components that are rendered inside islands. But again, this is very rare.

@saeho
Copy link
Author

saeho commented May 17, 2024

yes, that's what i assumed.

But what about inside islands where there are changing data that's passed down to stateless /components/ ?

For example:

  1. When creating a form, I'll have dynamic state changes inside /islands/
  2. When handling dynamic data without route changes such as an "infinite scroll" load more feature?

These 2 are good use cases where components need to re-render frequently. And I don't think these are rare cases, these are very common in every app.

In these 2 examples, should I only use memo() inside /islands/ ?

What about /components/ that are re-rendered frequently due to data changes in /islands/ ?

For example, if I have an infinite scroll list, and the list contains 1000 items. Those 1000 list items will be written in /components/, if the list data changes in /islands/ will that cause the 1000 item to re-render? Will it re-render 1000 more times every time the list gets appended? What do I do then?

Or how about a chat app? Same related problem there.

So what's the proposed solution in this case? Should I...

  1. import the stateless components from /components/ in /islands/ and the memo() each stateless component before using it?
  2. Or should I continue using memo() inside /components/ and expect that the memo() will be respected (ie. not a raw html) when I use it in /islands/ ?

Thank you. Please advise best practice.

@marvinhagemeister
Copy link
Collaborator

The component/ folder has no special meaning in Fresh, it's like any other folder. The more important distinction is if something is an island or rendered inside of one. If you render a list of 1000 items inside an island then these things start to matter. That said if you're rendering such a long list or something like a message view of a chat you you likely want some form of virtualization anyway, which is the proper solution to such a problem. If you combine that with some clever signal usage to bypass list rendering entirely, then the signals will automatically ensure that only the relevant parts will be updated. Think of them as automatic memoization on the data level.

@saeho
Copy link
Author

saeho commented May 17, 2024

I see, so your proposed solution is don't use memo() and rely on signals.
Got it. Make sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 participants