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

New tree view integration #864

Merged
merged 16 commits into from
Mar 18, 2019
Merged

New tree view integration #864

merged 16 commits into from
Mar 18, 2019

Conversation

brumik
Copy link
Contributor

@brumik brumik commented Oct 31, 2018

What: Added the react-wooden-tree to the storybook and initialized with a basic setup.
react-wooden-tree is a new tree view component, which should be integrated to the patternfly.

It is a modern and fast tree view component built for Red Hat as my bachelors thesis. It can be used as a navigation as well. It implements checkboxes, selects (in all form) and totally customizable trough classes.

The TreeView was built with performance in mind, with the help of benchmarks.

Additional issues:

The tree does not have design yet. Therefore this PR was created to to make the tree for other developers visible the integration to be able to help with the design.

Update from previous PR:

Continued PR #750 - Renamed the branch and was unable to reopen the PR.
Solved the issue with jest failed test with moving some dependencies in the react-wooden-tree component to the dev deps.

@Hyperkid123
@skateman
@priley86

@brumik brumik changed the title Wooden tree integration New tree view integration Oct 31, 2018
@patternfly-build
Copy link
Contributor

PatternFly-React preview: https://864-pr-patternfly-react-patternfly.surge.sh

@brumik brumik closed this Nov 7, 2018
@brumik brumik reopened this Nov 7, 2018
@brumik
Copy link
Contributor Author

brumik commented Jan 14, 2019

Status report

What I done:

I created the tree in PF as a separate package as @priley86 suggested in #750. Now it is working and patternfly-build was successful. Now you can check it out. The tree has nearly ready for the a11y. You can check out the progress at brumik/react-wooden-tree.

What I need to continue:

I was told to integrate the tree to the PF, so I will need some kind of design. (I am new, so I don't know in which form to expect it @Hyperkid123 ?). Getting the design should be enough to fully integrate to PF I hope. If not what else is needed to do?

@skateman

@skateman
Copy link
Member

@priley86 can you please give @brumik the requested input? It would be nice to get this in so we can finally use it.

@martinpovolny
Copy link
Contributor

martinpovolny commented Jan 21, 2019

I 👍 @skateman 's comment above. We need this component for ManageIQ.

Should this process take significant time (like an extra month) from now I am for moving this effort under https://github.com/manageIQ/react-ui-components.

In ManageIQ we preffer to contribute to Patternfly but if the price is months of waiting then we'd rather skip that.

.gitignore Outdated
@@ -14,6 +14,7 @@ packages/react-icons/src/index.d.ts
# package managers
yarn-error.log
lerna-debug.log
yarn.lock

Copy link
Member

Choose a reason for hiding this comment

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

please remove yarn.lock from gitignore

Copy link
Member

Choose a reason for hiding this comment

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

you may not find it useful in some downstream apps, but in a central repository like PF, it is common to check it in.

@priley86
Copy link
Member

thanks for splitting this into a separate package @brumik.

i've requested a review from @michaelkro - he is more familiar w/ the treeview.

@skateman
Copy link
Member

Related issue in MiQ: ManageIQ/manageiq-ui-classic#5178

stories.addDecorator(
defaultTemplate({
title: 'Catalog Tile',
description: 'This is a Tree View component to display trees and hierarchical data using React Wooden Tree.'
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we please add a link to react-wooden-tree's npmjs page

nodeIcon="fa fa-file-o"
data={this.state.tree}
onDataChange={this.onDataChange}
lazyLoad={this.lazyLoad}
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we spread props into <Tree /> for the remaining react-wooden-tree options?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am sorry, but I don't understand the question: what do you mean under spread?

Copy link
Contributor

Choose a reason for hiding this comment

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

I was thinking, say, if the consumer wants to take advantage of the loadingIcon option for <Tree />. With the current implementation, it does not seem possible to take advantage of the configuration.

If we added

<Tree
  ...
  {...this.props}
/>

it would allow the consuming application to make use of all the options available on this list

Or maybe, we could explicitly declare propTypes for all of the options?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So if I understood correctly, you want to get the default values of the props which are defined in the tree which is defined here and here? So it can be used in the parent component of the tree?

I cannot test but I pretty sure that you can use [String: Any] variable to define the props:

<Tree {...this.propsForTheTree} />

this should work if the propsForTheTree is defined correctly.

Copy link
Contributor

@michaelkro michaelkro Jan 24, 2019

Choose a reason for hiding this comment

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

Definitely agree that

<Tree {...this.propsForTheTree} />

would work :) However, please forgive me if I am missing something, but that would only work if the downstream application was doing something like

import { Tree } from 'react-wooden-tree'
// ...
<Tree { ...this.propsForTheTree } />

I have to admit that I'm not exactly sure how our yarn workspace works exactly, but my understanding is that after this package is added, the consuming application would be doing something like

import { TreeView } from 'react-tree-view`;
// ...
<TreeView { ...this.propsForTheTree } />

in which case, spreading props into TreeView would not work. What do you think?

EDIT: I removed the @patternfly from the package namespace. I think we're only using that for pf4

@brumik
Copy link
Contributor Author

brumik commented Jan 24, 2019

Added the required changes. Does it need any other changes?

@@ -0,0 +1,37 @@
{
"name": "react-tree-view",
Copy link
Member

Choose a reason for hiding this comment

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

this npm package name is already taken it seems... maybe something like patternfly-react-wooden-tree fits better?
https://www.npmjs.com/package/react-tree-view

Copy link
Contributor

@michaelkro michaelkro Jan 24, 2019

Choose a reason for hiding this comment

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

Once you've chosen a package name, I think the last thing we need will be to add a line to the README providing instructions on how to install the module. Something like

Getting Started

npm install <package_name> --save

require('react-wooden-tree/dist/react-wooden-tree.css');
require('./style.css');

const data = [
Copy link
Contributor

Choose a reason for hiding this comment

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

Uh oh, sorry that I missed this before, but this hardcoded data should probably get moved out of this file. Perhaps for now, you could create a file

patternfly-react-wooden-tree/src/components/TreeView/TreeView.fixtures.js

to be used for the storybook.

Looking at the npm documentation, I think we'll want to pass the tree data down to as a prop

constructor(props) {
super(props);

this.data = Tree.initTree(data);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we want this line to read

this.data = Tree.initTree(props.data);

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, we'll need a propTypes declaration too, to keep eslint from failing

propTables: [TreeView]
})(() => (
<div style={{ display: 'flex' }}>
<TreeView />
Copy link
Contributor

Choose a reason for hiding this comment

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

Once we've moved or imported the test data in this file, I think we want this to be

<TreeView data={data} />

}

render() {
return (
Copy link
Contributor

Choose a reason for hiding this comment

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

Since there will be at least one known prop data, we'll want to destructure that out before spreading the remaining props into <Tree>, like the following

render() {
  const { data, ...remainingProps } = this.props;
  
  return (
    <div className="App">
        <Tree
          nodeIcon="fa fa-file-o"
          data={this.state.tree}
          onDataChange={this.onDataChange}
          lazyLoad={this.lazyLoad}
          {...remainingProps}
        />
    </div>
  )
}

@michaelkro
Copy link
Contributor

I think we want the reworked changes from edef1ef right? (it seems that this commit was reverted)

@brumik
Copy link
Contributor Author

brumik commented Feb 6, 2019

Yes, I messed something up, I am sorry.

@brumik
Copy link
Contributor Author

brumik commented Feb 6, 2019

Now I believe its fine. Just the tests got some error (some options are deprecated), but I think its not a problem with my package as I didn't changed tests.

@skateman
Copy link
Member

@brumik please fix the yarn.lock conflict, @michaelkro if he does so, can this be merged or is there something else to do?

@brumik
Copy link
Contributor Author

brumik commented Feb 18, 2019

As @michaelkro said he is no longer working with RedHat, can you @priley86 provide what else you need after I merged the yarn.lock?

@brumik
Copy link
Contributor Author

brumik commented Feb 18, 2019

@priley86 I merged the yarn lock. The CI issues seem irrelevant.

@martinpovolny
Copy link
Contributor

@priley86 I merged the yarn lock. The CI issues seem irrelevant.

Yes, the same issue is on master. Seems the master is broken right now.

What is the overall status of this work? Are any further changes needed? Or can this be merged now?

Thank you, @michaelkro , @brumik , @skateman, for the great work!

@skateman
Copy link
Member

@priley86 could we please get this in ASAP? It's a little frustrating to have a merge conflict every second day but no progress. Thanks

@karelhala
Copy link
Contributor

@rachael-phillips can we add some people on review process here? It's been opened for quite a few days and no activity.

@dgutride
Copy link
Member

dgutride commented Mar 8, 2019

We are ready to take this in with a clean build - @brumik @martinpovolny - please contact me if you need somebody to take this on from our side so we can get it in today or Monday.

@brumik
Copy link
Contributor Author

brumik commented Mar 11, 2019

Hello, I used yarn 1.13.0 but the tests are failing: const { default: serializer, createSerializer } = require('./dist/js/build/jest/snapshot-serializer'). I don't know what is wrong.

@redallen
Copy link
Contributor

The problem is with our Enzyme version compared to your new React version (^16.6.1). React version 16.4.0 with these Enzyme versions is confirmed working:

    "enzyme": "3.3.0",
    "enzyme-adapter-react-16.3": "1.3.0",
    "enzyme-to-json": "3.3.4",

This is a problem I've only recently discovered and I hope to make a PR for today. Our yarn.lock was actually the only thing forcing the Enzyme versions to be correct.

@brumik
Copy link
Contributor Author

brumik commented Mar 11, 2019

So what should I do? @redallen

@redallen
Copy link
Contributor

redallen commented Mar 11, 2019

If you want to immediately get your changes through, use the versions I just said in all package.json files and update yarn.lock. For now I'd recommend waiting on #1541 which will fix tests and then merging those changes.

@jeff-phillips-18
Copy link
Member

You should be able to rebase now and resolve the conflicts. Should then be good to go

@brumik
Copy link
Contributor Author

brumik commented Mar 18, 2019

I did it, but the test still failing with:
Cannot find module './dist/js/build/jest/snapshot-serializer' from 'snapshot-serializer.js'

@jeff-phillips-18
Copy link
Member

@redallen Can you help here?

@karelhala karelhala self-requested a review March 18, 2019 13:42
@redallen
Copy link
Contributor

@brumik The build looks fine on my end with tests passing. If you run yarn install to upgrade enzyme, that will likely fix it locally for you. Good to merge if we can get someone else to approve.

@jeff-phillips-18 jeff-phillips-18 merged commit 9a50826 into patternfly:master Mar 18, 2019
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.

None yet