Things to improve

[tajo]

• in our baseweb application you can hover over component names in the editor and get a tooltip with flow types, we use extract-react-types-loader and the flexibility of prism-react-renderer to do that, solidify this API, add examples (including typescript)
• overall better support for typescript, propTypes, should be possible to add the type information into knob tooltips
• performance improvements, consider using sucrase as a primary compiler while keeping babel around for error messages, prettier and other less performance sensitive things, ideally we should be able to remove debounce and keep all actions (nearly) instant,
  Concurrent Mode should also help
• bundle size, react-view packs some big dependencies, we should be able to trim them down
• full-screen mode, some components have a lot of props and it's hard to see all playground components in a single view-port
• better documentation for advanced APIs customProps and provider, maybe explaning better how to parse ASTs and build them from scratch (the code generation part)
• better documentation around how react-view works internally
• prettier is now forked since it requires raw values in the AST + it's including unnecessary language extensions by default, let's figure out what to do about it ... maybe trim it even more and introduce some prettier-light version?

[awdyson]

Any chance we could get a roadmap at some point?

Appreciate the work by the way 😃

[tajo]

Maybe. Most of these are long-terms goals since they are not acute pain points for us. extract-react-types-loader might be more near-term. Hopefully, there will be some outside contributions too.

[raunofreiberg]

How would one go about using extract-react-types-loader to show TypeScript types? Would appreciate some pointers 🙂

[tajo]

How would one go about using extract-react-types-loader to show TypeScript types? Would appreciate some pointers 🙂

First you extract the types from the component file.

Then we pass it to the Editor component.

PropsTooltip has some vendored code that creates the definition out of that extract-react-types-loader datastructure.

You can see it at baseweb.design when you hover over components:

We use flow but should be almost same for typescript. Ideally, we don't want to vendor that code and enable this in a simpler way.

[raunofreiberg]

Thanks for the help!

If I may pick your brain — what do you think about using the extracted TypeScript (or Flow) types as props to react-view? It's probably harder to do with complex union types, but for primitives (string, boolean) it would likely avoid duplication.

[tajo]

If I may pick your brain — what do you think about using the extracted TypeScript (or Flow) types as props to react-view? It's probably harder to do with complex union types, but for primitives (string, boolean) it would likely avoid duplication.

It would be more trouble than help. The type extraction via extract-react-types-loader is far from being reliable and fails to extract props even in this case

const Component: React.FC<PropsT & { additionalProp: string }>

Even if it worked more reliably you still have to deal with more complex types like enums that often come with imports. And even "simple" boolean and string props sometimes need additional meta settings like defaultValue or stateful.

So in the best case scenario it would be some hybrid model. You would still have to maintain some configuration for each component.

Anyway, once you have these config files, you can actually use them for other things as well. For example, we generate these tables out of them (while using flow types as an additional information since they don't always work). And there are some other neat tools I want to build that will leverage the react-view props format.