-
Notifications
You must be signed in to change notification settings - Fork 443
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
fix: proxy localStorage and sessionStorage (closes #293) #548
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
32c0d0b
to
b77e380
Compare
Can you commit your tests for this too pls? |
I was also wondering if I could add the test for this. could you please advise me on how to do that? do we have an example of one e2e test suite but with a different config? like, I see |
you can add another |
ah sure, its a playwright script in the end of the day 🤦🏿 I will add more tests and let you know 👍🏿 |
In the current implementation, we cache both storages (localStorage and sessionStorage) at the moment of worker creation. Although this could be considered as performance optimization, it leads to the implementation inconsistency: - Storages data leaks into 3rd party script - Storages easily go out of sync as there is no proper synchronization with main window setup. - One can not override the storage access easily. For the latter point, this means we can not take on the methods like `localStorage.getItem()` in the Partytown proxy methods (specifically in `apply`). Hence there is no way to shield the storage data from 3rd party scripts. In this commit we fully rely on the storage values the main window sends into the worker. As the result, we can always receive relevant value and also can override the storage api with `apply` and `get` hooks
b77e380
to
5faa098
Compare
I have added the tests now 👍🏿 |
@gioboa could you please look into it again? |
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.
Thanks @n0th1ng-else it looks great
thank you Giorgio! Looking forward to contribute more |
What is it?
Description
In the current implementation, we cache both storages (localStorage and sessionStorage) at the moment of worker creation. Although this could be considered as performance optimization, it leads to the implementation inconsistency:
For the latter point, this means we can not take on the methods like
localStorage.getItem()
in the Partytown proxy methods (specifically inapply
). Hence there is no way to shield the storage data from 3rd party scripts.In this commit we fully rely on the storage values the main window sends into the worker. As the result, we can always receive relevant value and also can override the storage api with
apply
andget
hooksUse cases and why
Checklist:
Before
After