twenty/packages/twenty-front/src/modules/object-metadata/components/ObjectMetadataItemsLoadEffect.tsx

46 lines
1.5 KiB
TypeScript
Raw Normal View History

2024-03-26 13:19:40 +00:00
import { currentUserState } from '@/auth/states/currentUserState';
import { currentWorkspaceState } from '@/auth/states/currentWorkspaceState';
import { useRecoilValueV2 } from '@/ui/utilities/state/jotai/hooks/useRecoilValueV2';
import { useEffect, useState } from 'react';
import { useLoadMockedObjectMetadataItems } from '@/object-metadata/hooks/useLoadMockedObjectMetadataItems';
import { useRefreshObjectMetadataItems } from '@/object-metadata/hooks/useRefreshObjectMetadataItems';
[REFACTOR] `twenty-shared` multi barrel and `CJS/ESM` build with `preconstruct` (#11083) # Introduction In this PR we've migrated `twenty-shared` from a `vite` app [libary-mode](https://vite.dev/guide/build#library-mode) to a [preconstruct](https://preconstruct.tools/) "atomic" application ( in the future would like to introduce preconstruct to handle of all our atomic dependencies such as `twenty-emails` `twenty-ui` etc it will be integrated at the monorepo's root directly, would be to invasive in the first, starting incremental via `twenty-shared`) For more information regarding the motivations please refer to nor: - https://github.com/twentyhq/core-team-issues/issues/587 - https://github.com/twentyhq/core-team-issues/issues/281#issuecomment-2630949682 close https://github.com/twentyhq/core-team-issues/issues/589 close https://github.com/twentyhq/core-team-issues/issues/590 ## How to test In order to ease the review this PR will ship all the codegen at the very end, the actual meaning full diff is `+2,411 −114` In order to migrate existing dependent packages to `twenty-shared` multi barrel new arch you need to run in local: ```sh yarn tsx packages/twenty-shared/scripts/migrateFromSingleToMultiBarrelImport.ts && \ npx nx run-many -t lint --fix -p twenty-front twenty-ui twenty-server twenty-emails twenty-shared twenty-zapier ``` Note that `migrateFromSingleToMultiBarrelImport` is idempotent, it's atm included in the PR but should not be merged. ( such as codegen will be added before merging this script will be removed ) ## Misc - related opened issue preconstruct https://github.com/preconstruct/preconstruct/issues/617 ## Closed related PR - https://github.com/twentyhq/twenty/pull/11028 - https://github.com/twentyhq/twenty/pull/10993 - https://github.com/twentyhq/twenty/pull/10960 ## Upcoming enhancement: ( in others dedicated PRs ) - 1/ refactor generate barrel to export atomic module instead of `*` - 2/ generate barrel own package with several files and tests - 3/ Migration twenty-ui the same way - 4/ Use `preconstruct` at monorepo global level ## Conclusion As always any suggestions are welcomed !
2025-03-22 18:16:06 +00:00
import { isWorkspaceActiveOrSuspended } from 'twenty-shared/workspace';
import { isUndefinedOrNull } from '~/utils/isUndefinedOrNull';
export const ObjectMetadataItemsLoadEffect = () => {
const currentUser = useRecoilValueV2(currentUserState);
const currentWorkspace = useRecoilValueV2(currentWorkspaceState);
const [isInitialized, setIsInitialized] = useState(false);
const { refreshObjectMetadataItems } = useRefreshObjectMetadataItems();
const { loadMockedObjectMetadataItems } = useLoadMockedObjectMetadataItems();
useEffect(() => {
if (isInitialized) {
Fix metadata mocks loaded during login issue (#12446) If you tried to add a delay in `refreshObjectMetadataItems` like this` await new Promise((resolve) => setTimeout(resolve, 5000))`, then this caused an issue where the user was redirected to his workspace because the metadata was not loaded. This happened because I had removed the call to fetch metadata explicitly in useAuth (instead relying on the effect to fetch it because it was done twice). I had removed it because this was causing issues in the onboarding process where /metadata was called too early and then cached with the wrong reply. The correct fix is instead to change the fetch policy to `network only` to stop hiding re-renders to the object metadata effect with Apollo's cache mechanism. Now the [] reply isn't cached in the onboarding, the metadata effect is only triggered during initial page load and refresh should be called explicitely. I also noticed a bug on the server side where sometimes the frontend was passing a token for public requests (login token exchange request, public domain data request). I removed the check so that the backend completely ignores the token when it's passed on public request. The downside is that we're losing information for logs (who did that request to a public endpoint), but it doesn't make much sense to throw authentication errors on that endpoint imo. Probably a better root-cause fix would be to understand why a token is still passed on the frontend, but that would require more investigation — the bug happened when I was signing up and redirected from the app.xxx domain to the workspace domain
2025-06-04 09:01:30 +00:00
return;
}
Fix metadata mocks loaded during login issue (#12446) If you tried to add a delay in `refreshObjectMetadataItems` like this` await new Promise((resolve) => setTimeout(resolve, 5000))`, then this caused an issue where the user was redirected to his workspace because the metadata was not loaded. This happened because I had removed the call to fetch metadata explicitly in useAuth (instead relying on the effect to fetch it because it was done twice). I had removed it because this was causing issues in the onboarding process where /metadata was called too early and then cached with the wrong reply. The correct fix is instead to change the fetch policy to `network only` to stop hiding re-renders to the object metadata effect with Apollo's cache mechanism. Now the [] reply isn't cached in the onboarding, the metadata effect is only triggered during initial page load and refresh should be called explicitely. I also noticed a bug on the server side where sometimes the frontend was passing a token for public requests (login token exchange request, public domain data request). I removed the check so that the backend completely ignores the token when it's passed on public request. The downside is that we're losing information for logs (who did that request to a public endpoint), but it doesn't make much sense to throw authentication errors on that endpoint imo. Probably a better root-cause fix would be to understand why a token is still passed on the frontend, but that would require more investigation — the bug happened when I was signing up and redirected from the app.xxx domain to the workspace domain
2025-06-04 09:01:30 +00:00
const loadObjectMetadata = async () => {
if (
isUndefinedOrNull(currentUser) ||
!isWorkspaceActiveOrSuspended(currentWorkspace)
) {
await loadMockedObjectMetadataItems();
} else {
await refreshObjectMetadataItems();
}
setIsInitialized(true);
Fix metadata mocks loaded during login issue (#12446) If you tried to add a delay in `refreshObjectMetadataItems` like this` await new Promise((resolve) => setTimeout(resolve, 5000))`, then this caused an issue where the user was redirected to his workspace because the metadata was not loaded. This happened because I had removed the call to fetch metadata explicitly in useAuth (instead relying on the effect to fetch it because it was done twice). I had removed it because this was causing issues in the onboarding process where /metadata was called too early and then cached with the wrong reply. The correct fix is instead to change the fetch policy to `network only` to stop hiding re-renders to the object metadata effect with Apollo's cache mechanism. Now the [] reply isn't cached in the onboarding, the metadata effect is only triggered during initial page load and refresh should be called explicitely. I also noticed a bug on the server side where sometimes the frontend was passing a token for public requests (login token exchange request, public domain data request). I removed the check so that the backend completely ignores the token when it's passed on public request. The downside is that we're losing information for logs (who did that request to a public endpoint), but it doesn't make much sense to throw authentication errors on that endpoint imo. Probably a better root-cause fix would be to understand why a token is still passed on the frontend, but that would require more investigation — the bug happened when I was signing up and redirected from the app.xxx domain to the workspace domain
2025-06-04 09:01:30 +00:00
};
loadObjectMetadata();
}, [
currentUser,
currentWorkspace,
loadMockedObjectMetadataItems,
refreshObjectMetadataItems,
isInitialized,
]);
return <></>;
};