-
Notifications
You must be signed in to change notification settings - Fork 781
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
TypeScript definitions for 2.0.8 #969
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good, besides the comments I have given.
While the variable name is true in what it describes, I feel it's improved by naming it for what it _means_.
Nitpick: Rename constant for clarity.
Use `text(...)` instead of plain `string` in tutorial.
That's correct and it's also the expected result.
…On Thu, Jul 30, 2020, 07:55 Ron Martinez ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.d.ts
<#969 (comment)>:
> + }
+
+ // Virtual DOM properties will often correspond to HTML attributes.
+ type Prop = bigint | boolean | null | number | string | symbol | undefined | Function | ClassProp | StyleProp
+ type PropList = Readonly<ElementCreationOptions & {
+ [k: string]: Prop;
+ class?: ClassProp;
+ key?: Key;
+ style?: StyleProp;
+ }>
+
+ // A key can uniquely associate a virtual DOM node with a certain DOM element.
+ type Key = null | string | undefined
+
+ // The `class` property represents an HTML class attribute string.
+ type ClassProp = string | Record<string, boolean> | ClassProp[]
For sake of completeness, the following result is true?:
const isOpen = trueh('div', { class: ['menu', isOpen && 'open'] }, text('Hello'))
// <div class="menu open">Hello</div>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#969 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFYM2ZB76CXMAPD6ZEEM7DR6GCW3ANCNFSM4PDGZZTA>
.
|
`Transition` and `StateWithEffects` (especially the latter) were created to make typing the return types of actions easier to do. The benefit they provide is best seen when working with actions that return more than just an updated state. As a bonus they allowed the type definitions here to be further streamlined.
Minor documentation fixes; remove mention of payload filters, use `text` in examples.
@icylace With the following definition of function h<S, T>(
type: string,
props: T extends VDOM<S> ? never : T & PropList<S>,
children?: VNode<S> | readonly VNode<S>[],
): VDOM<S> demo: |
@icylace I discovered another issue with the types as they are at the moment. It seems that app({
init: [
{initial: 'state'},
initalEffect('http://foo.com')
],
...
}) But it looks like that is not allowed by the types even though it is a fully legal thing to dispatch. |
@zaceno Your suggestion for h("p", { style: { clor: "hi" } }) // $ExpectError
I'm trying to address this in accordance with your suggested change but it's tricky. If you have any ideas, that'd be great ! |
Sorry I don't know TS well enough yet. I don't even understand how that error could have come up, let alone how to fix it 😅 I guess it means What about other restrictions on h("p", {key: 42}) |
Isn't the point of types to help you catch errors before they happen? Why not also forbid going against best practice? What are types |
@jorgebucaran I think enforcing "best practice" with types is going to be bad for people who use typescript to write and compile their apps. Maybe that's what a linter is for (warnings without actually breaking your code).
I can't think of anything off-hand. Are you saying having an effect immediately on start up is a bad idea? |
Agreed. 👍 As for |
@zaceno I just updated the types to fix false positives for |
New and improved PR coming soon ! |
Please go here for the new PR: #1016 |
Here is an update to the TypeScript definitions I've made for Hyperapp.
Suggestions always welcome !