194 Matching Annotations
  1. Last 7 days
    1. For use$ since svelte is never going to support actions for components, i designed something that reminds React hooks that will in some ways replace this feature.

      Isn't that what use$ is trying to do already? How is that "something that reminds React hooks" any different? Will be interested to see...

    1. It's been a while since I had to write a typeahead without RxJS but this took some time and a lot of code. The implementation also contained fewer features, as the cancellability of previous requests. Sadly, most of the time, the implementation also introduced bugs. But with RxJS, this becomes trivial. By using some RxJS operators we end up with a working typeahead, without the bugs, which is thoroughly tested, and has more features. All of this, with less code.
  2. Nov 2020
  3. Oct 2020
    1. // Make a HOC
      // This is not the only way to accomplish auto-save, but it does let us:
      // - Use built-in React lifecycle methods to listen for changes
      // - Maintain state of when we are submitting
      // - Render a message when submitting
      // - Pass in debounce and save props nicely
      export default props => (
        <FormSpy {...props} subscription={{ values: true }} component={AutoSave} />
      );
      
    1. For the sake of best compatibility we convert the className attribute to class for svelte.

      Svelte refuses to standardize on any way to pass a CSS class. I thought className was actually the most common name for this prop though even in Svelte...

    1. (One can already destructure the loop variable but using a store obtained that way currently throws an error - Stores must be declared at the top level of the component (this may change in a future version of Svelte))
    1. When using React hooks there is no concept of onMount because the idea of only running some code on mount leads to writing non-resilient components, components that do one thing when they mount, and then don’t take prop changes into account.
    2. A component shouldn’t break because it’s rendered more or less often.
    3. Keep the local state isolated.Think about which state is local to a particular UI representation — and don’t hoist that state higher than necessary.
    4. Props and state can change, and components should handle those changes whenever they happen.
    5. Even if a component is rendered just once, your design will improve if rendering twice doesn’t break it.
    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.
  4. Sep 2020
    1. I took the same approach with _layout.svelte and not just for the svelte-apollo client. Except I put all of that setup into another module (setup.js) and imported from _layout. I just couldn't stomach having all that code actually in my _layout file. It's for layout, supposedly, but it's the only component that is a parent to the whole app.
    1. It looks like the issue stems from having "svelte" as a dependency instead of a devDependencies in package.json within the sapper project. This causes import 'svelte' to load the rollup excluded npm package's set_current_component instead of from within the sapper generated server.js.
    1. Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.
    2. I wrote hundreds of Rect components and what I learned is that Componets should be able to be styled by developer who is using it.
    3. color: red; //doesn't apply this rule, because scoping doesn't extend to children
    4. Say I want to style this javascript routing anchor tag on various pages (some may be buttons, plain links, images) it makes it incredibly difficult. Eg:
    5. Having to wrap everything in a selector :global(child) { } is hacky
    1. feel like there needs to be an easy way to style sub-components without their cooperation
    2. Allow creating custom components with the same abilities as native dom. By all means keep the same level of encapsulation, don't push class on components, but allow a component to mark the class property or another as a CSS Class property, in which case you could pass it through the same transformation that native elements go through
    3. The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.
    1. There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
    2. 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.
    3. 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.
    4. 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.
    5. This allows passing classes to child components with svelte-{hash} through the class prop and prevents removing such classes from css.
    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.
    3. They don't need to add a prop for every action. The action itself can be passed in as a prop. <script> export let action; </script> <div use:action>whatever</div> The argument for the action can be another prop or can be part of the same prop.
    1. Provides state management for tree-like components. Handles building a collection of items from props, item expanded state, and manages multiple selection state.
    1. One of the main reasons to work with components is re-usability and portability, but also a delegation of responsibilities. Adding a component should be as easy as simply adding the component without having to know the inner workings (or markup) of this component. A consumer should only be aware of the properties, methods and events of a component. In order to style a child component one has to be aware of the markup as well, which violates this 'delegation of responsibility'-principle.
    1. The primary motivation for this change is to have the same behavior between dom elements and wrapper components. Class directives are extremely convenient but that convenience is lost when a section of code needs to be converted to a component.
    2. This is especially useful for components that are a simple wrapper around a dom element.
    1. It’s become increasingly common to divide code into components, rather than by file type. React, for example, allows for the collocation of a components markup and JavaScript. In Svelte, this is taken one logical step further: the Javascript, markup and styling for a component can all exist together in a single `.svelte`​ file
    1. With Svelte, components and files have a one-to-one relationship. Every file is a component, and files can't have more than one component. This is generally a "best practice" when using most component frameworks.
    1. This is easily solved by extracting components, either as template partials/JavaScript components, or using Tailwind's @apply feature to create abstractions around common utility patterns.
  5. Aug 2020
  6. Jul 2020
    1. Also notice that the component name Nested is capitalised. This convention has been adopted to allow us to differentiate between user-defined components and regular HTML tags.
  7. Jun 2020
  8. May 2020
  9. Apr 2020
    1. It is not the browser's responsibility to auto-login to websites. This is the responsibility of the website you are accessing. The browser can remember form data and auto-fill for you, as can various extensions like LastPass.
  10. Mar 2020
  11. Dec 2019
  12. Nov 2019
    1. Null Components should never have children - they'd never be rendered.
    2. Aligning closely with the <Injector_ > naming convention, Null Components are denoted with a prefix and postfix _ (e.g. <_NullComponent_ />).
    3. The idea is that the additional prefix _ of a Null Component symbolizes that it adds even less to the DOM than an Injector. I picture the name falling through to become just the _, like the unused argument convention in javascript functions: const handleEvent = (_, id) => { console.log(id) } .
    1. However, in this case you would lose the possibility to render something in between. You are strictly coupled to the higher-order component's render method. If you need to add something in between of the currency components, you would have to do it in the higher-order component. It would be quite similar as you have done it previously by rendering the currency components straight away in the Amount component. If using a render prop component instead, you would be flexible in your composition.
    2. For the sake of completeness, the following code demonstrates that the problem could be solved with a higher-order component (HOC) as well:
    1. The terms “controlled” and “uncontrolled” usually refer to form inputs, but they can also describe where any component’s data lives. Data passed in as props can be thought of as controlled (because the parent component controls that data). Data that exists only in internal state can be thought of as uncontrolled (because the parent can’t directly change it).
    1. So the main thing this gives us is a way to set indeterminate property of input via an indeterminate property?

      This is misnamed. Doesn't actually give us a tri-state checkbox. Just a binary checkbox.

    1. input.indeterminate = indeterminate

      So the main thing this gives us is a way to set indeterminate property of input via an indeterminate property?

      Not sure how that supposedly gives us a tri-state checkbox.

    1. 3. Deployment as Memory Management

      The entire chapter 3 is worth reading. Great resource on what a package (or more broadly, a component) is in regards to Nix.

      Specifically "3.1 What is a component?"

  13. Oct 2019