Rename context to stuff
#984
Comments
|
Yes please! I frequently see confusion on why |
|
Should one be called |
|
I'm less concerned about the difference between My previous suggestion was
|
|
|
|
The overloaded use of
I propose changing
While we're discussing confusing naming, I think the "get" in
|
|
I just remembered the vanilla Svelte context API exists and already defines a
I tried mapping out the different flow of information for the two different
|
|
When |
|
I figured out how to replace
Bonus: easier to see the connection between Optional enhancements:
|
|
One more idea :
|
|
The core team just had a long conversation about this and we like function handle({ request, render }) {
request.locals.user = get_user(request);
return render(request);
}
function getSession(request) {
return {
user: sanitize_user(request.locals.user)
};
}We also spent entirely too long trying to come up with an alternative to layout context, but couldn't come to agreement. Some ideas that were floated, in no particular order of terribleness:
|
|
|
As an experiment, for each API we wish to name. Could someone write a single sentence to describe them? Only one sentence is allowed. |
|
The more I think about it the more I lean towards either <!-- src/routes/$layout.svelte -->
<script context="module">
import { createApiClient } from 'some-library';
export async function load({ fetch }) {
return {
inherits: {
api: createApiClient(fetch)
}
};
}
</script><!-- src/routes/somewhere/else.svelte -->
<script context="module">
export async function load({ inherits }) {
const { api } = inherits;
const banana = await api.get('banana');
return {
props: { banana }
};
}
</script>I should at this point note that the above code will have a subtle client-side bug once we implement #1277, in that the |
|
Why not call it provider/ provide / provision / supply or something? The layout provides some stuff and the child makes use of that provision. |
|
|
|
Our thinking was that the name should be the same in both places — we don't want a situation like <script context="module">
export async function load({ input }) {
return { output: {...} };
}
</script>
|
|
If
After keeping
I think any of these would work well:
|
|
I think we can make it clear that the two are linked without the name being exactly the same. E.g. if the layout output used |
|
I think using the same name does make sense because it feels like the same object. Like a train passing through multiple stations. We don't use a setter to set the context or a getter to get. Rather we set up an object and pass that through as an argument. Implementation may differ and the semantics aren't crystal clear but this i my mental model for it. @Rich-Harris While |
|
I was about to +1 yield, but can't use it: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/yield Need a word that can be destructured and not also reserved. I'm still pulling for |
|
Since |
|
Recent update of load / handle / getSession works great & clear, thanks. I have 2 questions or suggestions yet:
Feedback welcomed; I must admit this is my first time ever making a web app/site... ^^ |
|
Synonyms include |
|
|
|
Loading in, receiving, and/or passing <script context="module">
export const load = async ({ cargo }) => {
return { cargo: { ... } };
}
</script> |
|
@snoriq wrote:
You'll probably want to take a look at #1726 where I have a proposal that would allow that: I would add a
With my proposal, that could be handled by having the login code call Please let me know what you think, preferably over in #1726 so I have fewer issue comment threads to watch. :-) |
|
The decision has been made to rename |
benmccann
changed the title
context to stuff
There are a couple different places we use the word
contextloadhas acontextparametergetContextsetsrequest.contextAdding this here to track and have a discussion at some point since a couple maintainers have mentioned this as being something we might want to considers
Also, it looks like perhaps we should fix this TODO in the process:
kit/packages/kit/src/runtime/server/page/respond.js
Line 178 in 08ebcb5
The text was updated successfully, but these errors were encountered: