Patternfly-react: Component Contribution / Types

[priley86]

Component Contribution

What sorts of components would you like to contribute to this repository? Would you like to see components contributed independently (w/o) Redux integrations? Is there cases you'd prefer to see Redux used in the component definition?

Typescript, Flow, vs Vanilla JS

Would you like to use typings (such as Typescript or Flow)? Or do you prefer see vanilla es6 used in your React components?

Web Components

How soon would you be willing to adopt web components in your solutions (with the knowledge that IE10+ is often the limitation)? Would you be willing to test and ensure these meet the same JS API standards you have in your React components today?

[benjaminapetersen]

I'm willing to drop the first comment & a vote for vanilla JS! es6 has some great features for sure. Typescript would be my absolute least interest as I don't have deep roots on Java/C#. Flow does seem a bit more familiar and friendly to JavaScript idioms, but I certainly haven't looked into it enough to make a strong argument.

[priley86]

@benjaminapetersen thanks for weighing in. This is a really interesting subject at Red Hat right now which I've already heard several opinions on. I certainly see pros/cons of going with types. I'd like to support the most preferred option amongst this community. So anyone else who feels strongly about this, please help us out and weigh in here.

[benjaminapetersen]

Yeah does seem like TypeScript is gaining some ground around here. Anyone using Flow yet?

[gregsheremeta]

plain ES6 ++

[matobet]

Regarding Redux (or any "framework" dependencies for that matter) I will again contribute my $0.02 from work on https://github.com/oVirt/ovirt-ui-components.

We started by including in the repository both components that are "pure React" (just accept everything via props - data & handlers) and also their Redux-connected equivalents. This necessitated also co-location of reducers in the repo and tight coupling of the connected components to the structure of the Redux store of the target "host" application that ultimately consumed the components (and had to compose the store in a certain way...)

In the end we decided this was a mistake and currently we are in the process of migrating all "framework-aware" components away from the repository and want to keep there only "pure react" components that know nothing about Redux.

So it would be my advice to also keep those newly developed patternfly components "pure" and framework agnostic :-)

[jtomasek]

+1 for plain ES6 although we should have the infrastructure prepared to start using Flow if we decide so eventually.

According to Redux usage recommendations, there should not be a large amount of connected components inside the app. A general rule is that each route is controlled by a connected component and all it's children are receiving everything via props. Since the PatternFly components are supposed to be mostly presentational components (define how application looks, not how application business logic works - correct me if I am wrong here), majority of components should end up defined as a stateless functional components. In case when component needs to maintain state, component state should be sufficient.

[priley86]

@matobet +1 for "pure" and agnostic components. Thanks for noting this. I was leaning towards this & think it will be easier to maintain our UI components, but wanted to ask the community before we get started. We can always introduce some Redux examples in other demo/showcase apps.

@jtomasek agree on most components here being stateless functional components! :1st_place_medal:

@jtomasek would vanilla es6 components benefit your team now? It's sounding like this is a good place to start and would benefit most teams now, with a potential fork for Flow/Typescript in the future. Let us know if there is anything we should watch out for with this.

[jtomasek]

@priley86 yes, we're currently using vanilla es6. As mentioned in https://github.com/patternfly/patternfly-react/issues/3#issuecomment-286082627 patternfly-react components should be compiled such that they can be consumed regardless of the tools it uses

[vojtechszocs]

+1 on having ES6 code since that's what most (modern) JS projects use these days. ES6 allows to write cleaner code, compared to ES5. Transpiling to ES5 is usually part of project's build process - bring all (typically ES6 compatible) sources together and create an optimized bundle for deployment.

Redux is an architecture with JS implementation and React support. patternfly-react is used to provide UI components. It doesn't make much sense to have UI components impose a specific architecture/design concepts onto their users. In terms of Redux, shipped UI components should be strictly presentational and as simple/focused as possible, using composition to provide more complex components.

As for type safety, just like @jtomasek wrote, it's best to have an infrastructure prepared for using Flow at some point in future.

[priley86]

thanks @vojtechszocs for the feedback.

I am open to what the community feels best on this subject. It seems that many large software teams are moving to type safe JS (Flow, Typescript, etc) and I certainly understand the added benefits there. It also comes at a maintenance cost ;)

At this point, I do not want this to become a barrier to contributing, but agree it should be revisited again in the future. Please keep us posted on how soon your apps are moving in this direction.