28 Matching Annotations
  1. Jan 2022
    1. Maybe once the core onError lifecycle is implemented (if maintainers decide to go that way) everyone will discover you're right and an implementation will be built in. I think that's probably what's going to happen. But until real life has proved it, it's usually best to go for the smallest most broadly applicable solution. I can definitely imagine <svelte:error> eventually being a thing, but it's a pretty dramatic change compared to an added importable function.
  2. Jun 2021
    1. It was the first to present the concept of creating a function without a superfluous keyword function, replacing it with something that in 2015 was to become the function arrow (=> in ES6, -> in CoffeeScript). He also got rid of the curly braces (like Python), replacing them with indentations. Often in CoffeeScript, you can omit (once required) parentheses, that often unnecessarily decrement the readability of the code.
  3. Apr 2021
    1. Actually, I think your wife's point is quite astute. Once you become very familiar with this game, there is almost too much deep planning in the moves.
  4. Mar 2021
  5. Feb 2021
    1. No one has requested it before so it's certainly not something we're planning to add.
    2. To give a little more context, structures like this often come up in my work when dealing with NoSQL datastores, especially ones that rely heavily on JSON, like Firebase, where a records unique ID isn't part of the record itself, just a key that points to it. I think most Ruby/Rails projects tend towards use cases where these sort of datastores aren't appropriate/necessary, so it makes sense that this wouldn't come up as quickly as other structures.
  6. Nov 2020
  7. Oct 2020
    1. 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);
          });
        }, []);
      
  8. Sep 2020
    1. 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.
    2. 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.
    1. This has already forced me to forgo Svelte Material because I would like to add some actions to their components but I cannot and it does not make sense for them to cater to my specific use-case by baking random stuff into the library used by everyone.
    2. 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.
    1. 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.
    2. 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.
    1. 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>
    2. 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.
    1. 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.
  9. Jun 2020
  10. Mar 2020
    1. There is no use learning the word for “aardvark” in Swahili if you are never likely to use it. Think of words you use all the time and get familiar with them first.[2] X Research source For example, if you’re an exchange student in Russia, you might need to introduce yourself, ask for directions, and order food. While you might need to know the Swahili word for “aardvark” someday, you can learn it at a later date when the time comes.