-
Notifications
You must be signed in to change notification settings - Fork 31
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
feat: useAB with SWR (no Context or Provider) #4200
Conversation
Size Change: -26.6 kB (-2%) Total Size: 1.53 MB
ℹ️ View Unchanged
|
53e23d1
to
a6ffb21
Compare
a6ffb21
to
9b94183
Compare
This might not be fully baked yet… @OllysCoding feel free to pick up and modify as necessary. I think the failing tests are because App.tsx creates a distinct instance of |
9b94183
to
566e892
Compare
566e892
to
ea52d8d
Compare
ea52d8d
to
3ac7f87
Compare
3ac7f87
to
4a72524
Compare
4a72524
to
6eac789
Compare
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 made two comments but we've already discussed this in person and it's all good 👍
dotcom-rendering/src/web/components/ReaderRevenueLinks.stories.tsx
Outdated
Show resolved
Hide resolved
@@ -77,6 +71,13 @@ export const Page = ({ CAPI, NAV, format }: Props) => { | |||
shouldHideReaderRevenue={CAPI.shouldHideReaderRevenue} | |||
/> | |||
</Island> | |||
<Island clientOnly={true}> |
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.
Not really sure if this is a problem or not but is there a risk that we have code in other islands that starts to execute prior or in parallel to this initialisation?
We currently deal with dependency by putting things in the head but perhaps we can just early return in local components if there's a dependency?
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 this is down to consumer to make this decision. There’s a chance that the ABTestApi
is undefined. Most cases are already using a useOnce
, so it looks safe.
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.
Sounds good 👍
A hook which returns the AB Test Api when available, or undefined otherwise. Leverages an immutable SWR to satisfy all requests to the AB Core. As soon as the tests are available, all instances of the useAB hook will render. Previously, we had an AB Provider wrapped around App.tsx. With Islands, each island need to provide its own Provider, leading to much prop repetition. Co-authored-by: Olly <OllysCoding@users.noreply.github.com>
Favour lib/useAB instead – #4200 Fix tests for new useAB hook Co-authored-by: Olly <9575458+OllysCoding@users.noreply.github.com>
By using AB & setABTests in preview.js
13b0a37
to
2307f58
Compare
What does this change?
Leverages SWR to provide the
ABTestAPI
viauseAB
. Instead of using aProvider
, we have an Island dedicated to mutating the SWR cache (SetABTests
).This introduces a new pattern: SWR’s
mutate
, which is an a tool usually built for optimistic data mutation, where we don’t wait for the promise to resolve. In this specific case, the promise itself will never resolve, and we have to set the value ourselves.Why?
We currently need to have AB Providers for each Island that relies on the AB Test API. This leads to duplication of props and a lot more boilerplate code.
We want the platform to be as easy as possible to use.
See #3955