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

Migrate playroom internals to TypeScript #313

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

TheMightyPenguin
Copy link

Migrates internals to TypeScript. This PR is the first in a series of changes aiming to support Vite. This is the original PR #285, but following Michael suggestion to split up the work.

@TheMightyPenguin TheMightyPenguin requested a review from a team as a code owner January 6, 2024 06:05
Copy link

changeset-bot bot commented Jan 6, 2024

🦋 Changeset detected

Latest commit: 4425d38

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
playroom Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@TheMightyPenguin
Copy link
Author

@michaeltaranto @askoufis breaking down the Vite PR into smaller ones, this migrates files in the src/ folder to TypeScript, still somewhat chunky but should be easier to review as it should maintain the same current Playroom behavior.

Copy link
Contributor

@askoufis askoufis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for splitting out the PR. Just a few comments.

Comment on lines +5 to +6
"main": "utils/index.ts",
"types": "utils/index.ts",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to ship typescript as source? The alternative would be a build step. We could just run tsc for now, and graduate to something that offers proper CJS/ESM support later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reflecting on this, maybe for now we could just keep the separate .js and .d.ts files for simplicity, and think about a potential build process later on.

import RenderCode from './RenderCode/RenderCode';

interface FrameProps {
themes: Record<string, any>;
components: Array<any>;
FrameComponent: React.ComponentType<{
components: Record<string, ComponentType>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be ComponentType<any> so it will accept any component? Leaving out the generic argument results in it defaulting to {}, so only components that don't take any props would be accepted.

scope,
}: {
code: string | undefined;
scope: Record<string, ComponentType>;
Copy link
Contributor

@askoufis askoufis Jan 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think ComponentType is correct here. You can inject whatever you want with scope, a constant, a function, a component, etc. Maybe Record<string, any> would be more appropriate.

@mrm007 mrm007 mentioned this pull request Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants