-
-
Notifications
You must be signed in to change notification settings - Fork 926
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add type for PropsWithRef to define components that accept refs #778
Comments
How does that work for: let ref;
<Box ref={ref} /> Take note that Solid supports this. |
Yeah I know this works.. but when the ref comes from a parent.. its typed as a function, and annoying to type ourselves.. and more like an implementation detail |
Not exactly. Even though it is typed as a function after compilation, we lose support to the feature I mentioned which is like the most common way to capture refs. We should be consistent. In solid-headless, a union type for ref works: type Ref<T> = T | (val: T) => void; But normally, you only have to do this in the component: if (typeof props.ref === 'function') {
props.ref(el);
} of course, this is seamless: <div ref={props.ref} /> |
Ohh I thought passing a function in to ref is acceptable.. is that typed as an error? And is this Ref type exported from solid-js? |
passing a ref as a function is acceptable. My point was doing |
I don't thing the type should be used with let ref.. its only for props with ref that needs to be forwarded.. that has the awkward type.. so
but
ohh yeah maybe ur right in that those props need to include but I adding that makes sure that the user checks the function before trying to assign to it or something |
Surely, that's the downside, however usage of the ref feels more natural. |
Yeah no I agree being more explicit is better about the ref, but do we have the base Ref type in Solid? |
We don't. It's just an impromptu type I wrote 😂 |
The problem here is that we're assigning to I'm not sure how to improve this, because we can't make TypeScript think in the other direction here. |
@trusktr wouldn't really matter since we'll use it extend our props from anyway |
I fail to see how this has added value over |
@atk I rarely use declare function SomeComp<T>(props: SomeProps<T>): JSX.Element |
Thanks for the clarification. I think we should make the component/props types composable. There was also a discussion to add VoidComponents for components that do not allow children (because those would never be rendered). If we touch the types to define components, we should aim for a more complete version. |
* 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>}>`. <solidjs#778 (comment)>
* 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>}>`. <solidjs#778 (comment)> Fixes solidjs#778.
* 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 <ryansolid@gmail.com>
* resource and reactive updates, fix #919 * stores: top level arrays, prevent obj overnotify, fixes #960 batching mutable * fix #940 undefined ssr, fix #955 undefined className, fix #958 undefined spread * changelog wip * fix: fix the signal setter type when used with generics (#910) 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" ``` * refactor: improve splitProps type for arbitrary rest args length (#930) - 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 * v1.4.0-beta.0 * fix: spreading non-object props (#963) - `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, ref) (#877) * 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>}>`. <solidjs/solid#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 <ryansolid@gmail.com> * refactor: simplify effect types (#913) - 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 * optimize: use jest fake timer to test suspense (#964) fix #761 * new store modifiers splice, modifyMutable, bug fixes * v1.4.0-beta.1 * refactor: remove extra generic from modifyMutable (#965) * fix splice length setting * remove unnecessary splice * feat: resource deferred streaming * v1.4.0-beta.2 * support standard JSX transform * fix #967 `onHydrated` * v1.4.0-beta.3 * Different types for standard transform * v1.4.0-beta.4 * fix solid hyperscript, startTransition cleanup * fix build * v1.4.0-beta.5 * fix synchronous resources * more changelog updates * fix batch consistency in stores * v1.4.0-beta.6 * typescript: correct on helper types (#959) * 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 <ryansolid@gmail.com> Co-authored-by: Xavier Loh <42372774+otonashixav@users.noreply.github.com> Co-authored-by: Erik Demaine <edemaine@mit.edu> Co-authored-by: WZT <genuifx@gmail.com>
This type will be helpful and will the serve the purpose that forwardRef in react did. It allows us to easily define the ref type. The ref prop should be a function should that people don't use it by mistake and know that they either have to pass it or call it with the reference.
eg.
The text was updated successfully, but these errors were encountered: