-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
[NV-3735]: Improve launch darkly #5517
Conversation
✅ Deploy Preview for novu-design ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for dev-web-novu ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for novu-design ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
apps/web/src/AppRoutes.tsx
Outdated
<Route path="" element={<BrandingForm />} /> | ||
<Route path="layouts" element={<LayoutsListPage />} /> | ||
</Route> | ||
{!isInformationArchitectureEnabled && ( |
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.
🗒 note (non-blocking): Fix for information architecture -- previously didn't work due to LD
</SegmentProvider> | ||
); | ||
}; | ||
|
||
export default Sentry.withProfiler( | ||
withLDProvider({ |
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.
🗒 note (non-blocking): Moved LD provider to its own file in shared-web
with logic
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.
❓ question: why move to shared-web
?
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.
Most of our other similar providers are there, and many of the related behaviors / imports (i.e. useFeatureFlags
) are there, so it seemed best IMO
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.
🤓 nitpick (non-blocking): I suggest keeping it closer to the source of the web app unless we are sure it would be reused. Otherwise, we might end up with a landfill.
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 agree with @LetItRock. I feel that we might be overusing shared packages on some occasions. Other than that, great choice to split it into a separate component.
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, thanks for the feedback! Updated
const { [key]: featureFlag } = useFlags(); | ||
/** We knowingly break the rule of hooks here to avoid making any LaunchDarkly calls when it is disabled */ | ||
// eslint-disable-next-line | ||
const flagValue = checkShouldUseLaunchDarkly() ? useFlags()[key] : undefined; |
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.
🗒 note (non-blocking): Breaks the rule of hooks, but should be okay since it's done via a static check.
const ldClient = useLDClient(); | ||
|
||
useEffect(() => { | ||
if (!organization?._id) { | ||
if (!checkShouldUseLaunchDarkly() || !organization?._id) { |
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.
🗒 note (non-blocking): The client should never be defined anyway, but just as an extra fail-safe
|
||
useEffect(() => { | ||
// no need to fetch if LD is disabled or there isn't an org to query against | ||
if (!checkShouldUseLaunchDarkly() || !currentOrganization) { |
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.
🗒 note (non-blocking): Avoids any LD calls for initializing the provider
kind: 'organization', | ||
key: currentOrganization._id, | ||
name: currentOrganization.name, |
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.
question: If I understand this correctly, this will prevent us from having feature flags on the Onboarding and Signup pages right?
What if we still load launchdarkly in those pages but without the "context" ?
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'll investigate further. It definitely introduces some complexity, since they require fundamentally different things. Additionally, we're not handling this properly at the moment
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.
⚠ issue: blockers: sign up process and reset password are not working for me
Screen.Recording.2024-05-08.at.00.29.23.mov
Please make sure to run all e2e tests with this PR.
</SegmentProvider> | ||
); | ||
}; | ||
|
||
export default Sentry.withProfiler( | ||
withLDProvider({ |
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.
❓ question: why move to shared-web
?
@@ -49,6 +49,7 @@ import { useSettingsRoutes } from './SettingsRoutes'; | |||
|
|||
export const AppRoutes = () => { |
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.
🗒 note (non-blocking): the /auth/application
is not a protected route 😨
Great catch, thanks! This whole non-automated automated tests is beating me 🙃 |
c68d35c
to
c51c649
Compare
</SegmentProvider> | ||
); | ||
}; | ||
|
||
export default Sentry.withProfiler( | ||
withLDProvider({ |
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 agree with @LetItRock. I feel that we might be overusing shared packages on some occasions. Other than that, great choice to split it into a separate component.
libs/shared-web/src/utils/auth-selectors/selectShouldInitializeLaunchDarkly.tsx
Outdated
Show resolved
Hide resolved
libs/shared-web/src/utils/auth-selectors/selectShouldInitializeLaunchDarkly.tsx
Outdated
Show resolved
Hide resolved
Unfortunately, I am encountering some flakiness with tests, but I have verified manually that the behavior works. After talking with Sok this morning, we don't believe it's worth blocking on them since we'll be replacing them soon. Planning to merge this tomorrow morning after deployment breakfast |
Use async LaunchDarkly initialization, but ensure it works with self-hosted Why? Conditional routing (enabling routes based on feature flags) for Information Architecture is inconsistent, and causes issues with certain routes Resolves NV-3735
What changed? Why was the change needed?
Special notes for your reviewer
Repro
Basic
improve-launch-darkly
Old route hidden behind feature flag
Workflows
Check non-auth route
Self-hosted
web/.env.local
file (or whichever one you're using for local dev), comment outREACT_APP_LAUNCH_DARKLY_CLIENT_SIDE_ID
Network
tablaunchd
and nothing should appear