8000 POC new component for copying reports by snake14 · Pull Request #23308 · matomo-org/matomo · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

POC new component for copying reports #23308

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

Draft
wants to merge 8 commits into
base: 5.x-dev
Choose a base branch
from

Conversation

snake14
Copy link
Contributor
@snake14 snake14 commented May 21, 2025

Description:

This is a POC for a new component which can be used throughout the system for implementing the ability to copy reports and other entities, like goals, funnels, and so on. It uses some events to alert the parent of certain actions, such as validation. Some changes were made to SiteSelector to allow somewhat more configurability.

For right now, we're simply allowing one site and not allowing roll-up sites. We plan to add the ability to select more than one site at a time and come up with a better mechanism for determining whether roll-up sites should be allowed based on what is being copied.

Here is a test implementation:

image

The word 'report' is the default value for what is being copied and can be overridden using a prop. The div with the test form inputs is the slot defined by the parent view and is scrollable when it exceeds the available height. The copy button is disabled until validation passes.

Review

Copy link
snyk-io bot commented May 21, 2025

🎉 Snyk checks have passed. No issues have been found so far.

security/snyk check is complete. No issues have been found. (View Details)

@snake14
Copy link
Contributor Author
snake14 commented May 21, 2025

@caddoo Could some of the team look over this POC draft PR and give some initial feedback on the approach? They can use the Jira ticket PG-4019 as reference.

@sgiehl sgiehl requested a review from a team May 21, 2025 07:57
@james-hill-matomo
Copy link
Contributor

@snake14 LGTM, with the caveat that I'm new to the codebase. I've only looked at it from a PoC and structural point of view, and haven't reviewed any code in depth, or tested.

@caddoo
Copy link
Contributor
caddoo commented May 22, 2025

@caddoo Could some of the team look over this POC draft PR and give some initial feedback on the approach? They can use the Jira ticket PG-4019 as reference.

Appreciate the POC draft approach @snake14 .

As this is a POC, i will comment just on the code, the interface for other developers and also a bit on the UI.

Some feedback items ( I don't know how much are already decisions, so will just mention all ).

On the interface for the component.

I had to try and use it myself to try and understand how it works and came up with:

  <MatomoCopyModal
    v-model="showCopyModal"
    :copyEntityType="'dashboard'"
    :formData="copyFormData"
    @copySuccessful="handleCopySuccess"
    @resetFormData="resetForm"
  >
    <input v-model="copyFormData.title" placeholder="Enter new title" />
  </MatomoCopyModal>

Maybe naming a component other than MatomoCopyModal from reading it, I'm not sure if it's copying text or anything else intention isn't clear. But I also understand because it supports multiple entity types that might be difficult, but just raising as that may be an issue.

The property called copyEntityType looks like it should be a translated string to be displayed in the dialog. Maybe just name it 'modalTitle' and people can pass in something like 'translate('CoreHome_CopyX', 'dashboard')'. Clearer intention.

formData again could probably use a strict type or something, so it's clear what to expect as input (again might just be because PoC).

In terms of UI, it feels like an anti-pattern to have disabled submit buttons, the user doesn't know what to do in order to make it active. Usually they would be able to click it to see what is required, but again just opinion.

@snake14
Copy link
Contributor Author
snake14 commented May 23, 2025

Thank you @caddoo . Your example usage looks pretty close to what I was using to test. 👍
Please see my inline responses below.

Maybe naming a component other than MatomoCopyModal from reading it, I'm not sure if it's copying text or anything else intention isn't clear. But I also understand because it supports multiple entity types that might be difficult, but just raising as that may be an issue.

I'm definitely open to different name ideas. I simply went with MatomoCopyModal because it's generic enough that it could be used for copying a variety of things and it's similar to the existing MatomoDialog, MatomoUrl, ... components.

The property called copyEntityType looks like it should be a translated string to be displayed in the dialog. Maybe just name it 'modalTitle' and people can pass in something like 'translate('CoreHome_CopyX', 'dashboard')'. Clearer intention.

Yes. It's supposed to be a translated item. I could also adjust it to allow a translation key. I kept it somewhat generic because it's used by 3 translations in the component, including the title. Any occurrences of 'report' in the example screenshot I provided in the description are using the copyEntityType prop.

formData again could probably use a strict type or something, so it's clear what to expect as input (again might just be because PoC).

I could use some feedback around this. I thought about using an interface, but I also want to allow each usage of the component to provide the data required to make a copy. For example, one report might only need the report ID and the destination site ID while others might want to select additional options. Leaving the formData object open allows validating and POSTing the the unique data required by Goals, Funnels, Segments, ... to make a copy.

In terms of UI, it feels like an anti-pattern to have disabled submit buttons, the user doesn't know what to do in order to make it active. Usually they would be able to click it to see what is required, but again just opinion.

That's a fair point. I was thinking about the save button of some of our update forms starting out disabled until the form is 'dirty', but this is a different use case. I can change the submit button to be enabled until validation fails.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0