-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Dom: Add types #29220
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
Dom: Add types #29220
Conversation
Size Change: +221 B (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
Co-authored-by: Bernie Reiter <ockham@raz.or.at>
51694ef
to
c0b1f90
Compare
Rebasing this PR. I'll follow up with fixes. |
I think this PR is probably too big. I'd like to propose the following strategy instead of doing this all in one go:
As it stands I think there are too many logical changes that it's not really super safe or fun to review this PR. What do y'all think @sirreal @ockham? Additionally something seems to have affected bundle size. I wonder if it's optional chaining? |
I agree this is quite big and an incremental approach would be better. I tried to tackle this quickly while working on compose types, but it turned out much more involved. If you have a good plan to move ahead with it, please feel free to do whatever makes sense. I don't know when I'll be able to get back to this. Even if we don't split up and opt-in files to typechecking incrementally, changes can be landed incrementally in independent PRs with the goal of enabling typechecking. As I worked on this, there were places where it made sense to add protection. However, there are many unhandled nullable values that don't have an obvious improvement. In fact, hitting nullable values in many cases indicates the library is not being used correctly. In this case, runtime errors make a lot of sense, the library doesn't have a graceful way of dealing with some of these cases. I'm not sure how to best handle that, one option is to liberally add type assertions and leave the runtime alone. There's a lot of appeal to that 🙂 Another more radical option would be to add some assertions especially around the problematic nullable values and fail fast. Something like function assertIsDefined<T>(val: T): asserts val is NonNullable<T> {
if (val === undefined || val === null) {
throw new AssertionError(
`Expected 'val' to be defined, but received ${val}`
);
}
} |
Doing some cleanup to old PRs. This draft PR seems staled. should we close it? |
Description
Add types to
@wordpress/dom
package.Split out from #27344
Part of #18838
How has this been tested?
Screenshots
Types of changes
Checklist: