The issue has been closed

Typed `querySelector` with Strict Mode #3859

g-plane posted onGitHub

Introduction

Recently I've refactored and enhanced typed-query-selector module, together with a new feature called "Strict Mode".

The strict mode is implemented but not released at the time I create issue, but I'm planning to release v2.3.0 which includes this feature.

Details of strict mode can be found at readme but in a short word it performs a simple selector syntax checking and if selector syntax is invalid it will return never type. This feature won't be enabled by default and can be opted-in.

Benchmark

To be able to detect syntax errors of selector string, the selector parser has become complex, so I've run benchmark.

Environment spec

Item	Value
CPU	AMD Ryzen 5 2500U
RAM	8 GiB
Disk	SSD
OS	WSL 1
Node.js	14.15.1

Benchmark ran on this commit: https://github.com/sindresorhus/refined-github/commit/aa1904c847480f30d04a0b3c8c60da2c9bee8e48 with this command: node node_modules/.bin/tsc --noEmit --extendedDiagnostics

Benchmark result

<details> <summary>Before (<code>typed-query-selector</code> v2.2.4)</summary>

Files:                         469
Lines:                      131964
Nodes:                      434420
Identifiers:                145815
Symbols:                    137813
Types:                       31223
Instantiations:             212637
Memory used:               191410K
Assignability cache size:     9460
Identity cache size:           386
Subtype cache size:            753
Strict subtype cache size:     209
I/O Read time:               0.82s
Parse time:                  2.91s
ResolveModule time:          1.10s
ResolveTypeReference time:   0.10s
Program time:                5.35s
Bind time:                   1.70s
Check time:                  9.00s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                 16.05s

</details>

<details> <summary>After (non-strict mode) (<code>typed-query-selector</code> <a href="https://github.com/g-plane/typed-query-selector/commit/697ca7fee9f570b8a7171933cc233cd2a0b674f9"><code>697ca7f</code></a>)</summary>

Files:                         469
Lines:                      131989
Nodes:                      434520
Identifiers:                145841
Symbols:                    140450
Types:                       31651
Instantiations:             200005
Memory used:               197098K
Assignability cache size:     9721
Identity cache size:           386
Subtype cache size:            753
Strict subtype cache size:     209
I/O Read time:               0.72s
Parse time:                  3.01s
ResolveModule time:          0.99s
ResolveTypeReference time:   0.09s
Program time:                5.21s
Bind time:                   1.80s
Check time:                  8.88s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                 15.89s

</details>

<details> <summary>After (strict mode) (<code>typed-query-selector</code> <a href="https://github.com/g-plane/typed-query-selector/commit/697ca7fee9f570b8a7171933cc233cd2a0b674f9"><code>697ca7f</code></a>)</summary>

Files:                         469
Lines:                      132056
Nodes:                      434775
Identifiers:                145891
Symbols:                    140513
Types:                       31767
Instantiations:             200692
Memory used:               200499K
Assignability cache size:     9757
Identity cache size:           386
Subtype cache size:            753
Strict subtype cache size:     209
I/O Read time:               0.78s
Parse time:                  2.94s
ResolveModule time:          1.03s
ResolveTypeReference time:   0.09s
Program time:                5.25s
Bind time:                   1.60s
Check time:                  9.17s
printTime time:              0.00s
Emit time:                   0.00s
Total time:                 16.01s

</details>

Benchmark conclusion

Difference of ompilation time ("total time" in the result above) is so slight that can be ignored. However, memory usage is increased. For this project, it increased about 8 to 9 MiB.
Running type checking with strict mode will spend more time than non-strict mode.

Questions

How about this new feature?
Are there anything can be improved?

That sounds interesting but this project uses the package through select-dom, which probably can’t be strict. Maybe after #3855 we can use it directly.

posted by fregante about 4 years ago

Why cannot select-dom be strict?

posted by sindresorhus about 4 years ago

I don’t know what this change entails exactly, but if I make it strict any breaking issues/incompatibility with typed-query-selector suddenly become my issues. The parser isn’t fully compliant so I can’t make it a subdependency.

posted by fregante about 4 years ago

As select-dom being a library, switching to strict mode will be a breaking change for TypeScript users, and that's why strict mode in typed-query-selector won't be enabled by default. (but not affect JavaScript users because typed-query-selector only works at type level and there're no runtime code)

The reason why it's a breaking change is that if users pass invalid selector string, it will return never type, which may break their TypeScript type checking, but for valid selector string, everything works as before.

posted by g-plane about 4 years ago

Fund this Issue

$0.00

Funded

Pull requests

Typed `querySelector` with Strict Mode #3859

Introduction

Benchmark

Environment spec

Benchmark result

Benchmark conclusion

Questions

Company

Community

Support

Connect