22 Matching Annotations
  1. Last 7 days
    1. One of the consequences (although arguably not the primary motivation) of DRY is that you tend to end up with chunks of complex code expressed once, with simpler code referencing it throughout the codebase. I can't speak for anyone else, but I consider it a win if I can reduce repetition and tuck it away in some framework or initialisation code. Having a single accessor definition for a commonly used accessor makes me happy - and the new Object class code can be tested to hell and back. The upshot is more beautiful, readable code.

      new tag?:

      • extract reusable functions to reduce duplication / allow elegant patterns elsewhere
  2. Mar 2021
  3. Feb 2021
    1. Why is all this interaction code better? Two reasons: One, you can reuse the FindAccount interaction in other places, like your API controller or a Resque task. And two, if you want to change how accounts are found, you only have to change one place.

      Pretty weak arguments though...

      1. We could just as easily used a plain object or module to extract this for easy reuse and having it in only one place (avoiding duplication).
    1. You can optionally compose the steps manually (great for reuse) and just make use of the Runner#call method.
    2. What does this mean for our runner? They get simpler and allow for quick reuse! Let's see.
  4. Nov 2020
  5. Oct 2020
    1. Reusability: you can take advantage of many already built validations and you can easily promote your custom validations to reusable ones.
    2. You may want to reuse a list of curated third party validators without having to take the time to learn the signature of each validator.
  6. Sep 2020
    1. I've committed to using Svelte, so I want to see it become highly adopted and not die or lose steam. For that, I believe we need to build up the ecosystem. Shared components, actions, transitions, etc. which make it easier for ourselves and others to build apps. I feel this will help Svelte continue to grow and will make it a better tool for our jobs. I see actions as one of the needed pieces to make this happen.
    2. Actions aren't necessary, otherwise they would have been implemented from the start. But they do allow for easier code-reuse and better shared libraries without exploding/complicating the ecosystem.
    3. I think hooks will be beneficial to the Svelte ecosystem, making sharing code for Svelte apps that solve common problems easier.
    1. We should also allow passing unrecognised props to the rendered component. eg: tabindex might be required on some instances of a component, and not all. Why should developers have to add tabindex support to their components just that it may potentially be used

      Glad to hear this is solved now: $restProps

    1. This would be a component that is meant to be styled by its parents, and it would make no logical sense to have every possible type of style available inside the Link component. If I wanted to turn one of these anchor tags into a button, another into a nav-link, and another into a footer link, I should be able to. There's no reason that there shouldn't be a feature to treat a component like a normal HTML element.
  7. Jul 2020
    1. The key to successfully creating reusable components using both render props and scoped slots is being able to correctly separate behavior from presentation. Each time you create a new UI component, think “What is the core behavior of this component? Can I use this anywhere else?”