Solid 1.4 #974
Merged
Solid 1.4 #974
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
…ned spread
This makes it easier to create generic wrappers around `createSignal` e.g.
```ts
function createGenericSignal<T>(): Signal<T | undefined> {
const [generic, setGeneric] = createSignal<T>();
const customSet: Setter<T | undefined> = (v?) => setGeneric(v);
return [generic, (v?) => setGeneric(v)];
}
function createInitializedSignal<T>(init: T): Signal<T> {
const [generic, setGeneric] = createSignal<T>(init);
const customSet: Setter<T> = (v?) => setGeneric(v);
return [generic, (v?) => setGeneric(v)];
}
```
where previously such the implementation would not be assignable to `Setter`, and would need to be cast.
Unexpectedly this also makes this more specific:
```ts
const [s, set] = createSignal<string>(); // <-- signal contains undefined
// before:
const v = set(() => "literal");
// ^? - string
// after:
const v = set(() => "literal");
// ^? - "literal"
```
- Allows the return type of splitProps to be correct for 1 or more `...keys` passed - Removes overloads for `splitProps` as they are no longer necessary - Types each array passed as rest args as `readonly` as they do not need to be mutable
- `createComponent` passes an empty object instead of non-object props which are spread - `mergeProps` treats non-object sources as empty objects - added tests fixes #958
* Revised Component types (children, readonly, ref)
* Rename past `Component` type to `ComponentWithChildren`.
Motivation: Most components don't actually support children.
This causes a type error upon accidental passing of children /
forces you to think about which components support children.
* Added second parameter to `ComponentWithChildren`
to make it easier to give a custom type for `children`
(but still defaults to useful `JSX.Element`).
* New `Component` type does not have automatic `children` property
(like React's preferred `VoidFunctionalComponent`),
offering another natural way to type `props.children`:
`Component<{children: JSX.Element}>`.
* `props` argument in both `Component` and `ComponentWithChildren`
automatically cast to `readonly` (shallow one level only),
to avoid accidental assignment to `props.foo` (usually a getter)
while still allowing passing mutables in props.
Add `Props<T>` helper for this transformation.
* Add @lxsmnsyc's `Ref<T>` type so it's easy to type `props.ref`:
`Component<{ref: Ref<Element>}>`.
<#778 (comment)>
Fixes #778.
* Fix test
* Remove Props helper and shallow Readonly for props
* VoidComponent, ParentComponent, FlowComponent
* Use Component<any> for generic component type
* Add default types, Context.Provider require children
Comments from Otonashi
* Default parameter for PropsWithChildren
* Restore missing <any>
* Docs typo fix
* Cleanup server code
* JSDoc improvements
* Improve FlowProps JSDoc
* More FlowComponent JSDoc improvements
Co-authored-by: Ryan Carniato <[email protected]>
- Simplified `createEffect` etc. such that they no longer use rest args - Added test cases for effect functions failing partial generic inference (not supported by typescript) - Removed extra params from effects' first overload
* refactor: correct on helper types - Previous input type now includes undefined, which is its initial value - When defer is true, memos created with the on helper include undefined - Fixed return type becoming unknown when passing a function with a third parameter (the previous type) - Allow readonly arrays/tuples to be passed as deps - Disallow empty arrays from being passed as deps - Breaks backwards compatibility of the first generic; now it is the type of the inputs passed to the function instead of the type of the deps themselves: ```ts // before on<number>(() => 1, ...) // error on<() => number>(() => 1, ...) // ok on<[number]>([() => 1], ...) // error on<[() => number]>([() => 1], ...) // ok // now on<number>(() => 1, ...) // ok on<() => number>(() => 1, ...) // error on<() => number>(() => () => 1, ...) // ok on<[number]>([() => 1], ...) // ok on<[() => number]>([() => 1], ...) // error on<[() => number]>([() => () => 1], ...) // ok ``` * docs: update on helper jsdoc * fix: missing readonly in on helper types' `AccessorTuple` * refactor: allow any array in `AccessorTuple` - So that passing arrays works - Renamed to `AccessorArray` Co-authored-by: Ryan Carniato <[email protected]>
Pull Request Test Coverage Report for Build 2311620247
💛 - Coveralls |
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.
This PR merges in 1.4 branch.