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

KOGITO-2599: DataTable component API changes #332

Merged

Conversation

yzhao583
Copy link
Contributor

@yzhao583 yzhao583 commented Jul 22, 2020

Jira: https://issues.redhat.com/browse/KOGITO-2599

Create a DataTableColumn interface to represent a column for our DataTable containing:

  • path (required): jsonPath to the object property we want to show, this will be used to get the row cells value.

  • label (required): String for the table header

  • bodyCellTransformer (optional): a functions to convert the cell content to a different format for a better visualization. The function should return either a string with the formatted content or either a React Component to be displayed on the Table cell. As parameters it will receive:

    • value: the actual cell value (calculated by the column path attribute)

    • rowDataObj: the full object rendered on the row.

Many thanks for submitting your Pull Request ❤️!

Please make sure that your PR meets the following requirements:

  • You have read the contributors guide
  • Pull Request title is properly formatted: KOGITO-XYZ Subject
  • Pull Request title contains the target branch if not targeting master: [0.9.x] KOGITO-XYZ Subject
  • Pull Request contains link to the JIRA issue
  • Pull Request contains link to any dependent or related Pull Request
  • Pull Request contains description of the issue
  • Pull Request does not include fixes for issues other than the main ticket

@@ -8277,9 +8277,9 @@ escape-string-regexp@1.0.5, escape-string-regexp@^1.0.2, escape-string-regexp@^1
resolved "https://registry.yarnpkg.com/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz#1b61c0562190a8dff6ae3bb2cf0200ca130b86d4"
integrity sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=

escodegen@^1.11.1:
escodegen@^1.11.1, escodegen@^1.8.1:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yzhao583 I think this shouldn't be pushed...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pefernan Thanks for the review. I just installed the "jsonpath" package, don't know why so many dependencies got updated as well....

Are you suggesting not push local change of "yarn.lock"? Since I did not see it in the ".gitignore", so just want to confirm. Thanks
@cristianonicolai @AjayJagan @Sara4994

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a transitive dependency of jsonpath - this line specifies what versions were required either directly or transitively, wherease the decisive part is the line below - version "1.14.3" that's what actually got resolved as matching to all the "requirements" from above. And that version didn't change, so we're still on the same one.

But we should stick to a single registry url in yarn.lock imo - please run
yarn locktt --registry=https://registry.yarnpkg.com -s

More concerning is the esprima entry below - there we've added imo a second version of the same dependency.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jstastny-cz yea, I agree with the esprima.

@yzhao583 I know I already asked some changes on the design. But I think that, since the nested properties aren't required for now, we could rollback the that part and remove the jsonpath dep for now. I don't think we waht to have different dep versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jstastny-cz @pefernan If the change of "yarn.lock" in this PR is discarded, will the issue be fixed?
@pefernan I think the most important part of this PR is to support nested properties, if we decide to not have the feature for now, then I do not think it is necessary to have this PR opened.

Copy link
Contributor Author

@yzhao583 yzhao583 Jul 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pefernan @jstastny-cz I did some research about the issue, looks like we are not the only one to have the pain..and "esprima" is not the only dependency got duplicated. In our case, we have many dependencies got duplicated, such as "esutils", "eventemitter3", "extend-shallow", etc.

Looks like it is a issue has already been reported to yarn, here are some links to describe the issue:
yarnpkg/yarn#3778
https://medium.com/@scinos/de-duplicating-yarn-lock-ae30be4aa41a

Here are some solutions I found maybe useful:
https://medium.com/@bnaya/yarn-deduplicate-the-hero-we-need-f4497a362128
https://github.com/atlassian/yarn-deduplicate

In conclusion, this is definitely a issue that need our attention, but I would suggest to have a seperated PR to fix this, since it is related to so many dependencies and may need thoroughly test after the fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yzhao583 good point with https://github.com/atlassian/yarn-deduplicate.

I already seen that we are facing this issue of dupplicated deps with different versions

@jstastny-cz @cristianonicolai
To me I'd say that we should open a JIRA to fix that (. Seems like yarn deduplicate could solve the issue.) and continue with this PR.

Copy link
Contributor

@cristianonicolai cristianonicolai Jul 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to create a JIRA to look into yarn-deduplicate. That might actually be related to the issues we see when building on https://github.com/kiegroup/kogito-apps/pull/349.
I'm really just not sure how there two versions of "esprima" can coexist. @yzhao583 can you maybe that a look if we can safely use both?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi everyone, I was brought here by @cristianonicolai's PR mention.

I want to reassure you about having multiple version of the same module in the lock file. It's not a big deal, actually that's quite common when the dependency list grows. If a package needs an older version of a module already installed, there's no other way then install it and add it to the lock (the esprima example).

It's yarn (npm) job to install different versions in the right place, nesting node_modules inside deps that have specific version requirements, so that they will resolve the correct one.
The downside is an increase in the bundle size. Besides that, there are generally no issues for transitive deps. There are some exceptions though, like with multiple version of react for example. But when eventual conflicts arise, they hardly go unnoticed.

Regarding dedupe, its purpose is a bit different. yarn already takes care of de-duplication in most of the cases. Some special treatment is required when multiple versions of a specific module are resolved even when only one of them could suffice according to listed versions inside package.json . It could happen sometimes, especially for projects with a long lifetime (the order in which deps are added matters) and a high number of deps. Again, I don't think we should worry about it until we face a specific case requiring dedupe.

The only problem I see, already fixed, was the presence of npm registry urls inside yarn.lock.

Sorry for the intrusion :)

Copy link
Contributor

@pefernan pefernan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yzhao583 thank you very much, the code looks well and works perfect. The only issue is the transitive dep. Since that change isn't a blocking requirement I may remove the jsonpath dep, and leave that part as it was before.

@yzhao583 yzhao583 requested a review from pefernan July 23, 2020 19:31
@pefernan
Copy link
Contributor

@yzhao583 could you please rebase?

@yzhao583 yzhao583 force-pushed the KOGITO-2599-DataTable-component-API-changes branch from 5847371 to 6d21170 Compare July 29, 2020 18:40
@sonarcloud
Copy link

sonarcloud bot commented Jul 29, 2020

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 0 Security Hotspots to review)
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

@pefernan pefernan merged commit 9fb09c8 into apache:master Jul 30, 2020
domhanak pushed a commit to domhanak/incubator-kie-kogito-apps that referenced this pull request Dec 11, 2023
* [BXMSPROD-2016] Updating references to the new kie-ci actions folder.

* [BXMSPROD-2016] Updating references to the new kie-ci actions folder.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants