will persist snippet data across the login session

[Niharika0104]

Fixes - #399

[imrishabh18]

The snippet type shouldn't be undefined or string, when we are using the const names. It defeats the point of it

[imrishabh18]

Here as well, we shouldn't be using string

[imrishabh18]

@Niharika0104 Can you write a playwright test for this? And it would be better if you can split into multiple files

[Niharika0104]

@imrishabh18 Okay sure.So we should split tests across multiple files ?

[imrishabh18]

Yeah, Playwright tests took too much time if one file is having too many steps because of the wait time. Rather than that a better approach could be that small tests file with less steps, and that will be executed in parallel

[Niharika0104]

@imrishabh18 i'm unable to test these changes locally coz locally we are using fakeApi and not the redirecting the user to the github oauth page

the user will click on login to save button and when in prod env it will redirect user to the github oauth page and from there to the authorize page and if the authorize page sees that guest snippet variable exists in the local storage it will redirected to the editor page and I will extract the previous edited info from guest snippet and set it .Do we still need to write test for this coz i see that all the test's ran successfully.

[imrishabh18]

@Niharika0104 Yeah, correct. I think we can merge this without test. What do you think @seveibar?

On the UI, you have converted the Not logged in, can't save tag beside the save button to Login to save as a button. From the user point of view, that button appears to be a tag, which is pointing me to Login on the header and not click on the tag itself.

[Niharika0104]

@imrishabh18 yeah when we click on login to save it will redirect to GitHub oauth page and on entering their credentials it will redirect them to editor page and the code editor and manual edits json file will be populated with the info we saved in guest snippet variable present in the local storage.May be I should change its ui to look more like button rather than a simple tag
Hope this makes sense!!

[seveibar]

i think this breaks the loading of templates?

[seveibar]

@Niharika0104 I think this should be still testable in playwright if you create a fake-api login route, the url is something like:

• internal/oauth/github/authorize?next=${nextUrl}/authorize

Overall i like the implementation, except i think most users will click "login" in the header rather than the badge.

It's a bit of work but if you're down i would recommend pausing this PR, then implementing a PR that just allows logging in inside playwright tests (issue: #409)

Overall it's a good idea to store the guest session inside the global store. But I'm cautious about the loading process- we might want to have a specialized hook or something that runs the appropriate state machine because the <CodeAndPreview /> file scares me. But I'm not quite sure how to do this refactor yet-

[seveibar]

@Niharika0104 i was looking at the logic in a bit more detail, it seems like the playwright test should be able to login due to this login logic:

[Niharika0104]

Yeah the tests are fine now but when we click on login /sign up on the header it takes us to the home page(/) but when we click on the login to save button it will take us to GitHub oauth and then to the editor page.
I tried testing it in the vercel preview site but GitHub oauth is not working there @seveibar

[seveibar]

Yea i cant enable auth in preview

We should use the same code/logic for both logins, there's a sign in hook that should handle it iirc

[Niharika0104]

Yeah Im aware of that hook let me try again
Thanks @seveibar