refactor(lazy): update component type definitions to require 'x' prop#1910
refactor(lazy): update component type definitions to require 'x' prop#1910manudeli wants to merge 11 commits intofeat/stable-lazyfrom
Conversation
- Modified the `ImportCache` class to enforce that components must accept a prop `x` of type string. - Updated all relevant tests to pass the `x` prop when rendering lazy-loaded components. - Adjusted type definitions in `LazyOptions` to be more specific, enhancing type safety for lazy-loaded components.
People can be co-author:
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
…dering - Modified test assertions in `lazy.spec.tsx` to include the `x` prop in the rendered output of lazy-loaded components. - Ensured consistency in the expected output across multiple test cases, aligning with recent updates to the `ImportCache` class.
|
Size Change: 0 B Total Size: 81.8 kB ℹ️ View Unchanged
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## feat/stable-lazy #1910 +/- ##
=================================================
Coverage 94.05% 94.05%
=================================================
Files 41 41
Lines 656 656
Branches 167 168 +1
=================================================
Hits 617 617
Misses 36 36
Partials 3 3
🚀 New features to boost your workflow:
|
| interface LazyOptions<TComponentType extends ComponentType<any>> { | ||
| onSuccess?: ({ load }: { load: () => Promise<{ default: TComponentType }> }) => void | ||
| onError?: ({ error, load }: { error: unknown; load: () => Promise<{ default: TComponentType }> }) => void |
There was a problem hiding this comment.
@marshallku I don't know if we do type narrowing is better. but ComponentType is bad so I made suggestion
60e60ee to
1733815
Compare
If we stablize
lazy, Could we think about this type narrowing? orPromise<void>is better for return type ofload?