Add types for all pseudoclasses/elements

[appsforartists]

Uses type-fest and ${ prefix }key to teach the types about all possible pseudoprops (beyond the ones that were enumerated in the previous typing).

---

My first pass at this added types for all of the prefix keys to types.ts, because I didn't want to cause any concerns about circular imports. Then, I realized ./parseStyleProps is already being imported, so I tried to refactor to instead define them there:

export type PseudoelementKeys = keyof typeof pseudoelements;
export type PseudoclassKeys = keyof typeof pseudoelements;

That breaks the type in ways I'm not eager to diagnose, especially since you don't even know I'm writing this PR.

../jsxstyle-utils/src/types.ts:25:18 - error TS2411: Property 'animationComposition' of type 'false | AnimationComposition | null | undefined' is not assignable to '`${string}position`' index type 'false | Position | null | undefined'.

25 export interface CSSProperties
                    ~~~~~~~~~~~~~

../jsxstyle-utils/src/types.ts:25:18 - error TS2411: Property 'overscrollBehavior' of type 'false | OverscrollBehavior | null | undefined' is not assignable to '`${string}scrollBehavior`' index type 'false | ScrollBehavior | null | undefined'.

25 export interface CSSProperties
                    ~~~~~~~~~~~~~

../jsxstyle-utils/src/types.ts:29:3 - error TS2411: Property 'animation' of type 'false | Animation<string & {}> | JsxstyleAnimation | null | undefined' is not assignable to '`${string}animation`' index type 'false | Animation<string & {}> | null | undefined'.

29   animation?: BaseCSSProperties['animation'] | JsxstyleAnimation;
     ~~~~~~~~~

---

I do see some errors in npm run test, but they are the same with/without this PR.

[changeset-bot]

🦋 Changeset detected

Latest commit: bf100ab

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

This PR includes changesets to release 1 package

Name	Type
jsxstyle-utils	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

[appsforartists]

I just realized that hoverPlaceholderColor is an example given in the README, but not in the tests. I went to add it, and realized that format isn't actually supported:

    Snapshot name: `parseStyleProps splits out pseudoelements and pseudoclasses 1`

    - Snapshot  - 0
    + Received  + 1

    @@ -2,6 +2,7 @@
        "backgroundColor::selection": "red",
        "color::placeholder": "blue",
        "color:active": "purple",
        "color:hover": "orange",
        "outline:active": "none",
    +   "placeholderColor:hover": "red",
      }

[appsforartists]

I tried to test this locally, and it looks like main is quite divergent from what's currently on npm. (I don't even see jsxstyle/preact.) I'll have to rebase and try again.

Here's an archive of the 3.0 version:

https://github.com/appsforartists/jsxstyle/tree/pseudo-types-3

[appsforartists]

rebased onto 2.x and works!

[appsforartists]

And now CI is fixed too

[meyer]

Sorry for the delay here, I took a look when this PR dropped but didn’t have a chance to write some thoughts down.

The thoughts:

• Sorry for the extremely dusty main branch. I moved day-to-day development to the dev branch around March-ish of this year which has left main in a sad state. I’ve updated GitHub to use dev as the primary branch until I merge dev back into main.
• I’m about this 🤏 close to removing pseudoelement/pseudoclass prop prefixes entirely in favour of &-style prop names (already supported in jsxstyle@canary, context in the in-progress README rewrite branch). In-development jsxstyle still supports stripping prefixes off since there’s not too much runtime code required. I haven’t had any input for or against the feature though, so I’m open to input.
• I’m curious about the performance implications of ${PseudoelementKeys}${PseudoclassKeys}. I gave it a try with a full set of pseudoclasses and pseudoelements right when the feature dropped in TypeScript 4.1 but I ended up abandoning the idea due to slow style property type lookups. Given that string literal typing has been a thing for a while now, it’s highly likely that the feature has improved significantly for combinatorial cases.
• A PascalCase util is pretty easy to write, probably could skip the type-fest dependency. Just need to Uppercase a thing or two and that’s built in.

[appsforartists]

Thanks for taking a look!

I like that removing pseudos would make accessibility easier; however, that's a breaking change (e.g. on a 3.x branch)

Can I persuade you to merge this onto 2.x and release it? You're welcome to write a PascalCase type to replace the dependency. I'm not bothered either way, esp since it's a devDependency.

[appsforartists]

I just took a peek at your in-progress README. 3.x looks like a nice improvement! I'm particularly excited to have event handlers hoisted into props. props = { { onClick() {} } } never felt good.

[appsforartists]

I learned that Capitalize exists, so I was able to remove PascalCase.

Didn't push on Friday because inlining PrefixString was inexplicably breaking my types (JsxstyleProps was acting empty), but restarting Sublime seems to have fixed it.