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

Things to improve #2

Open
tajo opened this issue Nov 25, 2019 · 6 comments
Open

Things to improve #2

tajo opened this issue Nov 25, 2019 · 6 comments
Labels

Comments

@tajo
Copy link
Member

@tajo tajo commented Nov 25, 2019

  • 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?
@tajo tajo added the enhancement label Nov 25, 2019
@awdyson

This comment has been minimized.

Copy link

@awdyson awdyson commented Dec 17, 2019

Any chance we could get a roadmap at some point?

Appreciate the work by the way 😃

@tajo

This comment has been minimized.

Copy link
Member Author

@tajo tajo commented Dec 17, 2019

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

This comment has been minimized.

Copy link
Contributor

@raunofreiberg raunofreiberg commented Jan 8, 2020

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

@tajo

This comment has been minimized.

Copy link
Member Author

@tajo tajo commented Jan 8, 2020

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:

Screen Shot 2020-01-08 at 10 31 44 AM

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

This comment has been minimized.

Copy link
Contributor

@raunofreiberg raunofreiberg commented Jan 9, 2020

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

This comment has been minimized.

Copy link
Member Author

@tajo tajo commented Jan 9, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.