Skip to content
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

FTM: Implement new queryParams mechanism #30594

Closed
Tracked by #30598
KevinDavilaDotCMS opened this issue Nov 6, 2024 · 4 comments · Fixed by #30691, #30800 or #30809
Closed
Tracked by #30598

FTM: Implement new queryParams mechanism #30594

KevinDavilaDotCMS opened this issue Nov 6, 2024 · 4 comments · Fixed by #30691, #30800 or #30809

Comments

@KevinDavilaDotCMS
Copy link
Contributor

KevinDavilaDotCMS commented Nov 6, 2024

Parent Issue

#30598

Task

Implement a refined mechanism for query parameter (QP) handling to optimize page refresh processes in dotCMS UVE.

The current setup requires a page reload or refresh whenever a query parameter changes, which suits parameters like language_id, personaId, and variantName that alter page responses.
However, new parameters such as preview, orientation, and device will not impact page content but may cause unnecessary reloads if handled similarly.
This task requires restructuring state management for query parameters, making it reactive to only those parameters that impact page data while still reflecting all changes in the URL.

Proposed State Structure:

const uveState = {
  // Page parameters that trigger page requests when updated
  pageParams: {
    language_id: 1,
    personaId: 1,
    variantName: "DEFAULT",
    experimentId: 1,
    depth: 2
  },
  viewParams: {
    preview: false,
    orientation: "landscape",
    device: "desktop"
  },
  /* ... additional state properties */
};

Maybe we can split this logic in FeatureStore like withParams

Suscription

effect(() => {
   const params = this.uveStore.pageParams();
   // ...current logic
})

State initialization

ngOnInit(): void {
    const { queryParams, data } = this.route.snapshot;
    const canAccessClientHost = this.checkClientHostAccess(queryParams.clientHost, data.options?.allowedDevURLs);

    if (!canAccessClientHost) {
        // Remove `clientHost` from the QPs object
        delete queryParams.clientHost;
        // Optionally, remove `clientHost` from the browser search bar
        // To implement
    }

    this.uveStore.init(queryParams);
}

Proposed Objective

Core Features

Proposed Priority

Priority 2 - Important

Acceptance Criteria

  • Separate QPs into pageParams (requiring page refresh) and viewParams (UI-only changes without page reload).
  • Implement pageParams for parameters impacting data (e.g., language_id, personaId), which will continue triggering page refreshes on change.
  • Use viewParams for parameters like preview, orientation, and device to only update the store and URL without refreshing the page.
  • Ensure viewParams changes update both the store and URL in real-time without triggering a page reload.
  • All queryParams updates should synchronize with the Store state upon loading the page to ensure consistency in the URL and store values.
  • On the first load, retrieve and populate both pageParams and viewParams in the store based on the URL.
  • Maintain reactive updating of the URL based on store changes for all parameters.
@rjvelazco rjvelazco moved this from Current Sprint Backlog to In Progress in dotCMS - Product Planning Nov 20, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Internal QA in dotCMS - Product Planning Nov 26, 2024
@zJaaal zJaaal reopened this Nov 26, 2024
@github-project-automation github-project-automation bot moved this from Internal QA to Current Sprint Backlog in dotCMS - Product Planning Nov 26, 2024
@zJaaal zJaaal moved this from Current Sprint Backlog to Internal QA in dotCMS - Product Planning Nov 26, 2024
@zJaaal zJaaal self-assigned this Nov 26, 2024
@zJaaal
Copy link
Contributor

zJaaal commented Nov 27, 2024

IQA Failed

I found a loop when we navigate to experiments. I'll be addressing the fix since Rafa is out.

DotCMS Docker Image: [dotcms/dotcms:trunk_e15f58e]

Screenshot

Screen.Recording.2024-11-27.at.4.02.14.PM.mov

@zJaaal zJaaal moved this from Internal QA to In Progress in dotCMS - Product Planning Nov 27, 2024
@KevinDavilaDotCMS
Copy link
Contributor Author

IQA Failed

The loop is fixed, but i found other error on experiments tab when the user dont have an Analytics config

dotCms build number: e15f58e

Screen.Recording.2024-11-28.at.5.27.36.PM.mov

@github-project-automation github-project-automation bot moved this from Internal QA to Current Sprint Backlog in dotCMS - Product Planning Nov 28, 2024
@github-project-automation github-project-automation bot moved this from Current Sprint Backlog to Internal QA in dotCMS - Product Planning Nov 29, 2024
@nollymar nollymar reopened this Nov 29, 2024
@github-project-automation github-project-automation bot moved this from Internal QA to Current Sprint Backlog in dotCMS - Product Planning Nov 29, 2024
@nollymar nollymar moved this from Current Sprint Backlog to Internal QA in dotCMS - Product Planning Nov 29, 2024
@zJaaal
Copy link
Contributor

zJaaal commented Nov 29, 2024

IQA Passed

Now there are no loops nor errors in experiments

DotCMS Docker Image: [dotcms/dotcms:trunk_0e452b8]

Screenshot

Screen.Recording.2024-11-29.at.1.17.04.PM-1.mov

@zJaaal zJaaal closed this as completed Nov 29, 2024
@zJaaal zJaaal removed their assignment Nov 29, 2024
@zJaaal zJaaal moved this from Internal QA to QA - Backlog in dotCMS - Product Planning Nov 29, 2024
@nollymar nollymar moved this from QA - Backlog to Done in dotCMS - Product Planning Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment