Ben Durrant
Ben Durrant
it sounds like you might have a circular dependency issue - could you share a repo?
I'm inclined to agree that it's a little less black and white than that snippet makes it out to be. Generally I go by: - selector will return a new...
Invalidation will only make a request if you still have components subscribed to the data. If none of your components are using the data anymore, it'll be removed from store...
thanks! not sure when we'll next put together a release, but in the meantime the CodeSandbox build should hopefully suffice.
```diff -export const baseQuery: BaseQueryFn = async (props: BaseQueryProps, api) => { +export const baseQuery: BaseQueryFn = async (props, api) => { ``` does this help?
implement `v.partialBy(schema, v.exactOptional)` and `v.requiredBy(schema, v.nonNullish)` using HKTs
yeah, I'm not sure how possible configuring the modifiers could be - I'll have a play around it could be that something like `v.make(Schema, (entrySchema) => v.optional(entrySchema, default))` could work...
implement `v.partialBy(schema, v.exactOptional)` and `v.requiredBy(schema, v.nonNullish)` using HKTs
I've tested the object approach and it works well, it allows each key to correctly infer its configuration specifically
implement `v.partialBy(schema, v.exactOptional)` and `v.requiredBy(schema, v.nonNullish)` using HKTs
implement `v.partialBy(schema, v.exactOptional)` and `v.requiredBy(schema, v.nonNullish)` using HKTs
> A drawback with the object approach for the default values might be that it does not work for nonOptional, nonNullable and nonNullish. A workaround would be a second function...
implement `v.partialBy(schema, v.exactOptional)` and `v.requiredBy(schema, v.nonNullish)` using HKTs
no preferences on name i think the proposed modifier-per-key approach is nice for rare cases but clunky for more common cases the map-per-argument approach I've pushed works quite nicely for...