-
Notifications
You must be signed in to change notification settings - Fork 362
Upgrade to the latest SvelteKit #134
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
Conversation
badf42d to
db91603
Compare
| set(value) { | ||
| return getStores().user.set(value); | ||
| } | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't feel like the sort of code we want to be encouraging either. It's very confusing.
We're already exposing the user via data from +layout.server.js. We should just access the user everywhere via $page.data.user, not with this special store.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first commit in this PR used data.user everywhere, but it was a bit problematic because the only way to update it was to re-request the data. So if you want to do something like update the user display name you have to make one request to set it and then make a second request to get the data eventhough we already have it.
We had talked at one point about exposing SvelteKit's version of this so that users don't have to write special store handling code themselves. I think that would be a nice thing to do. Even if we don't use a store here, users do need to jump through some hoops if they ever want to use a store in their application for any other purpose
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another solution would be to make $page.data writable. If it were, then I could simply update it instead of needing to create a new store. That would also solve the remaining problem, which is that load is receiving an outdated version of data.user after login.
|
@benmccann I read in #137 that you are waiting for new features to be introduced before merging this. Do you have a timeline for these features? I know Removing session #5883 generated some backlash. |
| </li> | ||
|
|
||
| {#if $session.user} | ||
| {#if $user} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think under this new solution this evaluates as true all the time.
| {#if $user} | |
| {#if $user.username} |
|
Started work on a more comprehensive rewrite here: #139. I don't really understand what all the weird stores code is for here tbh! |
|
I'll go ahead and close this |
It's not pretty, but it works