Create unified types for nodes #2201
Merged
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
ong6
reviewed
Mar 13, 2023
tlylt
reviewed
Mar 15, 2023
jovyntls
force-pushed
the
ts-add-node-type
branch
from
a82413c to
dbf43e8
Compare
tlylt
reviewed
Mar 16, 2023
Co-authored-by: Liu Yongliang <41845017+tlylt@users.noreply.github.com>
|
LGTM, @raysonkoh want to take a last look? |
jovyntls
added a commit
that referenced
this pull request
Mar 21, 2023
Refactor core package to use Node types In #2201, we introduced a unifying type for nodes. Most of the core package is not yet using the new types. Let's refactor the core package to utilise these new types, and add a utility parseHTML method that avoids further `as unknown as` typecasts throughout the codebase. Doing so allows us to make full use of TypeScript's type-checking abilities while avoiding code duplication. For more information on the rationale of the unifying types, refer to #2201.
yucheng11122017
pushed a commit
to yucheng11122017/markbind
that referenced
this pull request
Mar 22, 2023
Refactor core package to use Node types In MarkBind#2201, we introduced a unifying type for nodes. Most of the core package is not yet using the new types. Let's refactor the core package to utilise these new types, and add a utility parseHTML method that avoids further `as unknown as` typecasts throughout the codebase. Doing so allows us to make full use of TypeScript's type-checking abilities while avoiding code duplication. For more information on the rationale of the unifying types, refer to MarkBind#2201.
ong6
pushed a commit
to ong6/markbind
that referenced
this pull request
Mar 23, 2023
Create unified types for nodes There is no standardised type for node variables, resulting in several undesirable issues: * `as unknown as` typecasts throughout the codebase * unnecessary checks on node attributes to satisfy the linter * incompatible types, treated as interchangeable in conversions Let's add common MbNode, TextElement and NodeOrText types that enforce attributes for nodes throughout the codebase. Doing so avoids the abovementioned issues, and formalises our view of the relationship between cheerio.Element, DomElement, and all the other attributes expected from node variables.
ong6
pushed a commit
to ong6/markbind
that referenced
this pull request
Mar 23, 2023
Refactor core package to use Node types In MarkBind#2201, we introduced a unifying type for nodes. Most of the core package is not yet using the new types. Let's refactor the core package to utilise these new types, and add a utility parseHTML method that avoids further `as unknown as` typecasts throughout the codebase. Doing so allows us to make full use of TypeScript's type-checking abilities while avoiding code duplication. For more information on the rationale of the unifying types, refer to MarkBind#2201.
This was referenced Mar 24, 2023
Merged
tlylt
pushed a commit
that referenced
this pull request
Mar 31, 2023
Clean up & standardise TypeScript conventions The core package is almost fully migrated to TypeScript. There are several inconsistencies and redundancies in how we represent common types, handle typecasts, and export/import files. These inconsistencies may cause confusion, reduce code quality, and prevent us from fully taking advantage of static typing. As of #2201 and #2221, we have a more mature typing system that we can utilise to fix these inconsistencies as well as a general set of conventions that can be followed across TS files. Let's, - Standardise class exports - Standardise key-value types to use `Record<K, V>` - Remove unnecessary `as unknown as` typecasts - Reduce the use of `any` types - Fix outdated docs that refer to `.js` files Using Record is preferable as `Record<K,V>` is interchangeable with `{ [key: K]: V }` syntax, but is more extensible and arguably more readable. `unknown` and `any` types also introduce uncertainty and unsafe typecasts into the codebase.
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 is the purpose of this pull request?
Fixes #2114 (the creation part)
Overview of changes:
Creates MbNode, TextElement and NodeOrText types. This avoids unnecessary and unsafe typecasting later on, and creates clearer distinction between how we handle nodes.
This PR implements a minimal "demo" to preview how the changes will look like. Further refactoring may be done in future PRs.
Anything you'd like to highlight/discuss:
Naming of the typeRenamedNode- seems to clash with many other types. WouldNodeElementbe a better name?MbNodeTesting instructions:
N/A, there should be no difference in behaviour
Proposed commit message: (wrap lines at 72 characters)
Checklist: ☑️