[Discussion] How to create bussiness logic components?

[karelhala]

Since patterfly is our main pattern library framework and react is starting to be used accross multiple projects it would be nice to create couple of business logic components, e.g. more complex components to be used accross multiple projects.

This repository is really great way how to style and create multiple components as building blocks for each application. However it lacks some more complex components which can be used in bigger projects. Let's take as example tagging component, which is used accross multiple projects, but it lacks complex and mainly unified UX design patterns.

Possible sollutions

From my point of view we have two ways of how to deliver such complex and unified components to multiple projects

1. Create components in this repo (current state)

Drawback of this sollution is that this repository will get big and eventually it will mean loading a lot of JS just to use simple components (I know that treeshaking should take care of it, but why rely on it). Plus we can't create components which are using redux because this repository is not setup in a way of exposing redux related things.

2. Create new repository which would use basic patternfly react components (porposition for discussion)

Drawback may be that eventually components in such repo might be forgotten. But we could expose much more things in such repo and build on top of simple components created in patternfly-react, use redux, expose actions and reducers and use them in final application. We used to have something similiar for angular's components called ui-components, I started to work on react related components which might be used in ManageIq, however I feel like these components should be part of patternfly.

Conclusion

Basically what I propose is shared GH repository for multiple teams where they'd create their complex components which can eventually be shared amongst others.

Repo which is in process of setting up react-ui-components, lot's of things are still missing (mostly CI/CD), but basic understanding of how this can be used can be seen there.

[priley86]

@karelhala thanks for raising this (I think others have as well). I think our long term plan is to move this repo to a monorepo. We have another issue on this topic started here:
#201

Does this help? Would you be OK closing this issue and referencing that one?

[karelhala]

@priley86 yeah, that basically answers my question. I should have looked into issues before rasing this one. So closing it and I'll continue discussion in #201.

[priley86]

hey @karelhala - i am thinking about this a bit more... just would like some clarity since it is a good question. Do you see the need to potentially create alternative repos for specific products or the potential to create more shared UI components that are specific to PatternFly? I guess that is the key distinction here... if they are UI components specific to PF, I would think they would live here. We also decided to share other UI components like the SerialConsole here as well (and that would be a good use case for the monorepo in the future). That component currently does not have PF design (but we are incorporating that UI component to help multiple teams). If they are not specific to PF, then I would guess you can organize as necessary though (so it is up to the product team to organize as needed). But long term, I would think most or all UI components should go through PF design review once they have been formalized for sharing amongst teams.

@serenamarie125 @jeff-phillips-18 @jgiardino thoughts on this issue? Not sure if we are just revisiting the same question, or this is something different...

[karelhala]

Well there might not be need for additional repos per product. But it would be beneficial since patternfly can work on core components with their own merge/review process and repo for multiple teams/repo per team can be managed by said team. However this can be achieved by letting other's merge in monorepo of patternfly (don't know how that can be possible).

I aggree with you that all UI components (simple or complex) should be patternfly's, but that's quite long run and a lot of rewriting to be done. So from my point of view I'd create new repository for others to do more complex components, less strict review process, multiple people from multiple teams can merge there and such. PF folks can provide UX designs there as well and review it. This might sound like we'd be splitting work PF team, but I see it beneficial because a lot of teams are creating same components all over again, instead of collaborating and reusing components different team used.

What are your thoughts about this? I am not sure how this can be achieved, either monorepo with multiple subdirectories for each type of component, new repositories or what to use.

PS: Basically it would be nice to have core react components which would not hold any state. And complex components which can use redux or whatever the team behind such component would like to use.

[priley86]

@karelhala we had a short conversation this morning in the maintainer meeting. We are looking to open up some meetings to others in the future (so look for an invite if you are interested).

From the sounds of it, we can start introducing domain specific components in a new directory here in PF-React for now. However, all newly introduced components should go through a proper vetting process (and I believe @jgiardino and @serenamarie125 are following up on that). Again, these are just cases where the components are new (w/o PF design docs) and potentially being shared.

So maybe we further breakdown src/components into hierarchical groups (Storybook would support this now as well)... in the long term, we break those into the monorepo packages.

@jeff-phillips-18 would you like to make a proposal on this new folder structure for everyone?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[dgutride]

Moving to closed - we are now using a monorepo and support extension packages for items like this