Update Types

[icylace]

This PR was originally about App<S> but has evolved into a pervasive update.

Changelog:

• Added TypedH<S>. It lets you define a version of h that has your app's state type "baked in" so you don't need to worry about whether or not you need to explicitly assign the generic type parameter for h every time you call it.
  • Originally from: Add the new TypedH<S> type. #1049
  • Addresses: Usage with TypeScript #1048
• Added the utility types AllOrNothing<T>, AtLeastOne<T>, and IndexableByKey. They assist the implementation of some of the other types which are refactored accordingly.
  • These utility types might be useful to the user in their own right.
• Improved App<S> to validate all combinations of app() props usage.
• Improved validation of using event actions with custom payloads.
  • For instance, this should be treated correctly now: h("p", { onclick: [MyAction, 42] }, text("hi")).
• Made the payload parameter of Effecter<S, P> and Subscriber<S, P> definite.
  • This follows from discoveries found during discussions of: Types: enable definite payloads #1045
• Removed EffectCreator<S, D>. I don't believe it adds enough value even on a purely self-documenting code basis.
• Removed Payload<P> because in the places where it could appear either a parameter name or named tuple could express the same level of detail.
• Removed State<S> for partially the same reason as removing Payload<P>. Another reason was I wanted to prevent potential confusion on the user's end about whether State<S> is required like how StateWithEffects<S> is.
• Added Dispatchable<S>. It simplifies a couple type definitions while adding more meaning. It can also be handy to the user when defining effecters and subscribers.
  • Based off of @zaceno's idea for a dispatchable type.
• Added names to tuple types. This helped with the rationale for removing Payload<P> and State<S>.
• Added a types reference to index.d.ts in package.json per @talentlessguy's suggestion.
• Renamed some generic type parameters.
• Added a little more commentary.

---

Original PR title and text for posterity:

Improve the App type

This fixes certain cases when using App. I've also added a little more commentary in some parts of the type definitions.

Here are the relevant lines in the types test suite if you're curious:

• https://github.com/icylace/hyperapp-types-tests/blob/4ebe6e928945184bfb96321d40cfa6a88b058686/test/api/app.test.ts#L26
• https://github.com/icylace/hyperapp-types-tests/blob/4ebe6e928945184bfb96321d40cfa6a88b058686/test/api/app.test.ts#L36-L73

[zaceno]

Overall I really like this update! 👍 👍 The utility types I could take or leave but the rest is great. I haven't actually tried it out in practice yet but I trust @icylace ;)

There is one thing I've been thinking about though. And it is the names of Action, ActionTransform and ActionWithPayload.

As I see it, the one that users will most commonly import and use in their own code will be ActionTransform. The others will mainly be used when users implement their own effects & subs I think.

So, compare:

const Add : ActionTransform<State, number> = (state, amount) => ({...

vs

const Add: Action<State, number> = (state, amount) => ({...

I would prefer the latter. I know - the latter already actually works, probably anyway, but I feel like there is something wrong with defining a const as some type which is actually a union type.

So I'm thinking what if we could rename:

ActionTransform -> Action
Action -> ??? maybe Handler? or ActionType

Or just get rid of the current Action and inline Action | ActionWithPayload where it was.

... or of course we could leave things as they are for now and think more about this. But I wanted to raise the question anyway.

[jorgebucaran]

Or just get rid of the current Action and inline Action | ActionWithPayload where it was.

Works for me! 👍

[icylace]

I'd rather keep Action or rename it if necessary. I'm using it a lot in a UI library I'm working on. It's used in configuration objects for my components that need to reference actions.

Also, there's another option:

const Add = (state: State, amount: number): State => ({...

[zaceno]

Yeah if you're using the current Action type a lot then let's keep it of course.

But I do think we should keep considering renaming it to something else to free up the name "Action" to be used in place of "ActionTransform". The more I think about it the more important I think this is.

At least, when I say "action" I always mean the function. I never think of or explain [DoFoo, 32] as a special kind of action. Rather it is a way to customize the payload the actual action gets dispatched with. Actions are such an important concept I think we need to be very specific how we communicate precisely what an action is and isn't. But also I can see how that question is beyond the scope of this PR. Let's keep it going in Discord or Github Discussions.

[jorgebucaran]

I do think we should keep considering renaming it to something else to free up the name "Action" to be used in place of "ActionTransform".

Makes sense to me. 👍

[icylace]

Just renamed Action to Reaction and ActionTransform to Action.

[icylace]

Latest change removes Transform because it ultimately isn't essential and is arguably too specialized.

[icylace]

Just updated the PR with the following changes:

• Added a variation of @zaceno's ValidateCustomPayloads type to help solve custom payloads.
  • Optimized away some type variables accordingly.
• Added some more commentary and reformatting.

[jorgebucaran]

Do you think you can make a CodeSandbox example or share a snippet to can see how you're using these types?

[icylace]

Do you think you can make a CodeSandbox example or share a snippet to can see how you're using these types?

Yeah, I'll be doing something along those lines to show how to use these types.

Up until now I've been relying on my test suite to work them out but that code is not necessarily approachable.