Block Serialization Default Parser: Include TypeScript type declarations #43722
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gziolo
added
Developer Experience
gziolo
force-pushed
the
update/block-parser-ts
branch
from
16cec77 to
9ddd499
Compare
|
Size Change: -12 B (0%) Total Size: 1.24 MB
ℹ️ View Unchanged
|
gziolo
force-pushed
the
update/block-parser-ts
branch
from
9ddd499 to
31033aa
Compare
gziolo
commented
Aug 31, 2022
| const next = nextToken(); | ||
| if ( next === null ) { |
There was a problem hiding this comment.
This refactoring was driven by TypeScript that wasn't quite happy about the token being an array with 1 item or 5 items. It turns out that when using null instead the array with 1 string item, the behavior remains the same, and we can bail out earlier to avoid other operations that aren't necessary for this case anyway.
There was a problem hiding this comment.
did you look at using [TokenType, string?, Attributes?, number?, number?]?
the refactor looks fine but I'd rather we return 'no-more-tokens' than null because of the self-documenting nature of the string value.
There was a problem hiding this comment.
Yes, that was my initial try, but TS was complaining about the number of items in the array returned: 1 instead of 5. Maybe return [ 'no-more-tokens', , , , ]; would work then?
There was a problem hiding this comment.
I opened #44459 to address it.
gziolo
added
the
[Feature] Parsing
dmsnell
reviewed
Sep 10, 2022
There was a problem hiding this comment.
Thanks for adding type definitions here @gziolo
A couple broad questions:
- Did we consider creating a
types.d.tsfile instead for the public API to avoid having to litter the JSDoc comments throughout the code? That is, maintain full internal type unity vs. document the public API? - If we are going to fully-type the code, and the code is fairly straight-forward, why not go ahead and write it with full TypeScript support and avoid the more awkward JSDoc comments?
| const next = nextToken(); | ||
| if ( next === null ) { |
There was a problem hiding this comment.
did you look at using [TokenType, string?, Attributes?, number?, number?]?
the refactor looks fine but I'd rather we return 'no-more-tokens' than null because of the self-documenting nature of the string value.
That seems like an improvement to what we have now.
However, that would be my preferred approach. My initial idea was just to get it to work, and JSDoc approach seemed like the most straightforward path forward for both the reviewers (smaller diff) and me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR adds types to the
@wordpres/block-serialization-default-parserand exposes TypeScript types for the package.Why?
To increase the code quality and the documentation.
It's also part of an effort to add types to
@wordpress/blockspackage that depends on this package.How?
Adds JSDoc comment with types for
@wordpres/block-serialization-default-parser.Testing Instructions
All CI check should pass. Locally,
npm run build:package-typesshould finish with no errors.