feat(typescript): Added TypeScript Type Defs #322
Conversation
Pull Request Test Coverage Report for Build 1272
💛 - Coveralls |
|
i'm not at all opposed to this if it helps others @dmiller9911. can you provide some docs/notes on how one would contribute these alongside the new components that get added? I think we will have several folks who are new to Typescript. Ideally we only need to support a single type system in this repo if that is the preference (would not like to put the burden of multiple type systems on the contributors). As I mentioned in some other threads - I'm am still quite interested to see where the React community as whole sways on this topic in the coming months... years. Right now it does seem that Typescript and Flow are still the most widely used type systems for Javascript / ECMAScript 2017, and I believe these can promote good patterns in the codebase. In the long term, I would also like to keep an open mind toward new type systems which may compile to web assembly instead of just transpiling to ECMAScript (and I am assuming Typescript will become one of these translators). I am quite bullish on WASM as a whole (there is a plethora of coming use cases it will target) and I have begun researching it on the side for opportunities which would complement current React JS/current PF designs. The simple fact is - transpiling to the JS as a VM (LLVM) is not exactly the same as compiling other statically typed languages in use today, but Typescript gives a good emulation of this. However, I do not view AOT type systems/JS typed systems to be as performant or as safe as what WASM will provide in the future. See bits here about upcoming WASM safety. It is also evident that current browsers are highly optimized for Javascript and are only beginning to be optimized for WASM. One of the inherent limitations of Javascript that WASM will overcome is the reliance on browser implementations of garbage collection and memory management (see garbage collection notes on MDN). I expect many core JS libraries on the web today to move this direction once support improves (and it does seem that JS will be supported via Chakra Core). This is one reason I think we should keep an open mind on this topic. Like everyone else, I am very curious to see how the state of typed Javascript evolves in 2018/2019/and beyond... I'm curious to hear other's thoughts and thanks for raising this one! |
|
@priley86 totally agree on WASM vs TS/Flow. That said they are both used in the community. I am not sure of any flow apps within Red Hat, but I do know of a few TypeScript based patternfly-react apps. We can put this in DefinitivelyTyped if others are wanting to keep it out of this repo, but that poses more of the issue of the typings getting out of date. For example here are a few widely used libs in the React eco system that provide typings are part of their package: I will look at adding some docs around contributing types. I believe that most of the repos above have specific people contributing Typings isntead of it being a whole team effort type of thing. I would be nice for the ones contributing to also contribute types, but I don't know that we should force them. I think starting with the TypeScript consumers being responsible for them would be ok. |
Added type defs for typescript applications consuming patternfly-react
|
rebase * 😆 |
|
@priley86 Any interest in continuing on this? |
|
@jeff-phillips-18 in the short term no, however in the next few months, potentially yes. I think it's OK to close this for now though and we can re-reference the PR afterward. thanks! |
Added type defs for typescript applications consuming patternfly-react
What:
Added typescript definition files for all components and utilities that are exported from patternfly-react.
** Why here and not DefinitelyTyped?**
Typings that live in the repo are more likely to stay up to date than ones living outside the repo.
Link to Storybook:
N/A
Additional issues:
Depends on: patternfly/patternfly#1043