213 Matching Annotations
  1. Apr 2021
  2. Mar 2021
    1. First of all, I would say it is not good to use margin on the component’s top-level, because it breaks the isolation of components.// A React component with margin set on top-levelconst MyComponent = () => { return <div style="margin: 1rem">...</div>;};margin here is not just affecting the component itself, but also affecting other components (e.g., it is pushing off another component / element sitting next to it)If we want to place this component in a different context or layout, margin would get in the way of resuse


      • コンポーネント外の他のコンポーネントに影響を与えてしまう。(例えば、位置を変えてしまうなどの副作用)
      • 他のレイアウトやコンテキストでコンポーネントを再利用しづらくなってしまう
    1. Suppose that the validate task was getting quite complex and bloated. When writing “normal” Ruby, you’d break up one method into several. In Trailblazer, that’s when you introduce a new, smaller activity.
  3. Feb 2021
    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. 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.
  4. Jan 2021
    1. Thanks to that I have chance and time to properly initialise all the properties without reactive calls and I do not have to ignore these "initialising" events before proper initialisation.
    1. Knowing exactly what happens in your application can mean the difference between feeling in full control or experiencing deep frustration. Personally, unknowns drive me crazy, which in turn often leads to all sorts of experiments and/or debug sessions.
    1. Theemergence of the termcontent strategyitselfrepresents widespread recognition that componentcontent management was in great need of aroadmap.

      For me this is one of the key sentences of this paper. It is impossible to understand content strategy without taking component content management into consideration. For an academic approach to content strategy component content management is a key.

    2. In its most commondefinition, a genre is a rhetorical action that istypified and socially recognized based on recurrentsituations; members of organizations use genresfor specific communicative and collaborativepurposes [6], [7]

      This might be translated following the approach of semiotic practices defined by Fontanille et.al.

  5. Dec 2020
    1. What is a data-originated component? It’s a kind of component that is primarily designed and built for either: displaying, entering, or customizing a given data content itself, rather than focusing on the form it takes. For example Drawer is a non data-originated component, although it may include some. Whereas Table, or Form, or even Feed are good examples of data-originated components.
    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]]

  6. Nov 2020
    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.
  7. 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.
  8. 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. 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.
  9. Aug 2020
  10. 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.
  11. Jun 2020
  12. May 2020
  13. 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.
  14. Mar 2020
  15. Dec 2019
  16. 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: