Skip to content

Conversation

mcmah309
Copy link
Contributor

@mcmah309 mcmah309 commented Aug 15, 2025

This PR renames the server hooks to match their normal hook counterparts and better reflect their intent. By matching the normal hook counterparts it is immediately clear to users that are familiar with their counterparts what their functionality is. Additionally, the current server naming is very confusing to new comers. The existing names suggest the hooks will run on the server, but that is not entirely true. They may run on client as well. Their use is during hydration. As such, they should be renamed to reflect this. Thus:

  • use_server_cached -> use_hydration_hook
  • use_server_future -> use_hydration_resource

@mcmah309 mcmah309 requested a review from a team as a code owner August 15, 2025 16:37
@mcmah309 mcmah309 changed the title refactor: Rename server hook to match counterparts refactor: Rename server hooks to better fit their use Aug 15, 2025
@ealmloff
Copy link
Member

I like the future -> resource rename, but I'm somewhat concerned the hydration name will cause people to use these hooks over use_resource and use_hook where it isn't needed. The hydration in the name makes me think that the hook should be used instead of the original if you are using hydration which isn't the case.

use_hook and use_server_cached do very different things. use_resource and use_server_future are fairly similar, but use_server_future always suspends

@mcmah309
Copy link
Contributor Author

mcmah309 commented Aug 20, 2025

Anyone who uses the hydration hooks over the normal hooks I assume understands hydration, so I wouldn't be too concerned over them using it everywhere.

use_hook and use_server_cached do very different things.

If not compiled on web or server, it is just use_hook. If on web and used outside hydration (data not available) it also is just use_hook. If used correctly, it becomes a hook whos value is supplied through hydration. Thus I think use_hydration_hook is a perfect name.

use_resource and use_server_future are fairly similar, but use_server_future always suspends

Yeah but "future" here implies it will act like use_future, but it is more similar to use_resource, in fact it returns a Resource (though wrapped in another suspend).

In all I'm more concerned (and have experienced this myself) that "server" causes confusion rather than "hydration" (which is it's intended use).

@mcmah309
Copy link
Contributor Author

mcmah309 commented Sep 2, 2025

@jkelleyrtp as with our talk

https://discord.com/channels/899851952891002890/928812591126569000/1407446528653656245

are you wanting to get this in with 0.7? I can resolve the new conflicts if that is the case.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants