25 Matching Annotations
- Feb 2021
-
en.wikipedia.org en.wikipedia.org
-
it is inconvenient to write specific implementations for each datatype contained, especially if the code for each datatype is virtually identical. For example, in C++, this duplication of code can be circumvented by defining a class template
-
-
- Nov 2020
-
github.com github.com
-
Note that you can also use dynamic partials, that conditionally select the partial to render based on the value in the JSON.
-
- Oct 2020
-
stackoverflow.com stackoverflow.com
-
we update the validation schema on the fly (we had a similar case with a validation that needs to be included whenever some fetch operation was completed)
-
-
codesandbox.io codesandbox.io
-
export const validationSchema = { field: { account: [Validators.required.validator, iban.validator, ibanBlackList], name: [Validators.required.validator], integerAmount: [
Able to update this schema on the fly, with:
React.useEffect(() => { getDisabledCountryIBANCollection().then(countries => { const newValidationSchema = { ...validationSchema, field: { ...validationSchema.field, account: [ ...validationSchema.field.account, { validator: countryBlackList, customArgs: { countries, }, }, ], }, }; formValidation.updateValidationSchema(newValidationSchema); }); }, []);
-
-
www.basefactor.com www.basefactor.com
-
What would happen if we get the list from a rest api when the form component is mounted? That's an interesting topic, you can add a rule once a component has been mounted and update the associated validation schema.
-
Ok, I have seen that there are lot of built-in and third party validations, but sooner or later I will face a validation rule not covered by this buffet. Can I build a custom one? Of course you can!
-
- Sep 2020
-
github.com github.com
-
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
-
Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
Tags
- forking to add a desired missing feature/change
- being explicit
- Svelte: how to affect child component styles
- workarounds
- ugly/kludgey
- maintenance burden to explicitly define/enumerate/hard-code possible options (explicit interface)
- burden
- trying to prevent one bad thing leading to people doing/choosing an even worse option
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- explicit interfaces
- maintenance burden
- component/library author can't consider/know ahead of time all of the ways users may want to use it
- forced to fork/copy and paste library code because it didn't provide enough customizability/extensibility / didn't foresee some specific prop/behavior that needed to be overridable/configurable (explicit interface)
Annotators
URL
-
-
github.com github.com
-
The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.
Tags
- flexibility
- pass-through arguments/props/options
- run-time dynamicness/generics vs. having to explicitly list/hard-code all options ahead of time
- extensibility
- Svelte: action (use:)
- component/library author can't consider/know ahead of time all of the ways users may want to use it
Annotators
URL
-
-
github.com github.com
-
Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.
-
-
-
You'll have to create a new component that brings in the functionality of both. TooltipButton, TooltipLink, Link, and TooltipRoutedLink. We're starting to get a lot of components to handle a bit of added functionality.
-
For the tooltip example, if you had a whole bunch of tooltips on different elements, it would be annoying to have different event listeners and "should it be shown" variables for each one.
-
-
-
Perhaps at that point we're better off settling on a way to pass components through as parameters? <!-- App.html --> <Outer contents={Inner}/> <!-- Outer.html --> <div> <div>Something</div> <[contents] foo='bar'/> </div>
-
I would hope for it to come with React-like behavior where I could pass in a string (like div or a) and have it show up as a normal div/a element when the child component used it.
-
-
github.com github.com
-
Use case: Wrapper components that need to render an element (e.g. because they attach event listeners). You'd probably use a <div> there by default but there may be places where this is not desirable for semantic reasons (e.g. in lists).
-
-
-
const components = { Label, Tree, Menu };
-
-
github.com github.com
-
The lack of spread continues to be a big pain for me, adding lots of difficult-to-maintain cruft in my components. Having to maintain a list of all possible attributes that I might ever need to pass through a component is causing me a lot of friction in my most composable components.
-
- Aug 2020
-
ocharles.org.uk ocharles.org.uk
-
In other words you cannot choose the definition of a value based on its type (for now).
What does this mean?
-
- Nov 2019
- Oct 2019
-
www.typescriptlang.org www.typescriptlang.org
-
Using Type Parameters in Generic Constraints
-