38 Matching Annotations
  1. 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.
  2. Dec 2020
    1. Sometimes, systems just scale the problemA UI design system is more than the code of a component library. It’s more than the colors, styles, and margins of your elements. It’s an ever-growing and ever-evolving creature that entails your brand and your user’s feelings.

      If you don't understand the problem - you can [[scale the problem instead of solve the problem]], and it's important to remember that a [[design system is more than a component library]]

  3. Nov 2020
  4. Oct 2020
    1. In general it is recommended you handle forms in this "controlled" manner. In some cases it might make sense to manage the form state outside of Solid via refs. These "uncontrolled" forms can also work. Just be conscious of the difference as mixing approaches can lead to unexpected results.
  5. 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.
    3. The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
    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.
  6. Aug 2020
  7. Jul 2020
  8. Dec 2019
  9. Nov 2019
  10. Aug 2019