14 Matching Annotations
  1. Jan 2024
    1. This is true for other tasks besides design — frontend implementation, backend implementation, QA, etc — would we create unique types for each? Our suggestion here to teams today is often to break down the work into issues, or now tasks, for each uniquely assignable/trackable piece of work. You could do the same for design, where the task or issue is used to track status, discuss progress and maybe even WIP, but is focused on being SSOT for status rather than design.
    2. Personally I think we could get a ton more benefits and would also be able to pull new users into our platform by finding better ways to integrate/link/connect/display Figma in our work item objects. Today the biggest downside for "Design management" is that it's basically just a copy of what's happening inside of Figma that has to be manually kept in sync and requires users to constantly switch back and forth:
  2. Feb 2023
    1. Event Replay: If we find a past event was incorrect, we can compute the consequences by reversing it and later events and then replaying the new event and later events. (Or indeed by throwing away the application state and replaying all events with the correct event in sequence.) The same technique can handle events received in the wrong sequence - a common problem with systems that communicate with asynchronous messaging.
  3. Dec 2022
  4. Sep 2022
    1. As a reminder, the JSON Schema is not the source of truth for the Specification. In cases of conflicts between the Specification itself and the JSON Schema, the Specification wins.
    1. As a reminder, the JSON Schema is not the source of truth for the Specification. In cases of conflicts between the Specification itself and the JSON Schema, the Specification wins. Also, some Specification constraints cannot be represented with the JSON Schema so it's highly recommended to employ other methods to ensure compliance.
  5. Jan 2022
    1. Oh, I just figured out a workaround for my project, in case it helps someone. If you want the source of truth on the prop to come from the child component, then leave it undefined in the parent. Then, you can make the reactive variable have a condition on the presence of that variable. eg: <script> let prop; $: prop && console.log(prop); </script> <Child bind:prop/> Might not work for every use case but maybe that helps someone.
  6. Oct 2020
    1. In the next major, we'll start copying the ref onto both the props and the element.ref. React will now use the props.ref as the source of truth for forwardRef and classes and it will still create a shallow copy of props that excludes the ref in these cases. At the same time, we'll add a getter for element.ref in DEV that warns if you access it. The upgrade path is now to just access it off props if you need it from the element.
  7. Aug 2020
    1. Do not include the same information in multiple places. Link to a SSOT instead.
    2. There is a temptation to summarize the information on another page. This will cause the information to live in two places. Instead, link to the SSOT and explain why it is important to consume the information
  8. May 2020
    1. Code Owners allows for a version controlled single source of truth file outlining the exact GitLab users or groups that own certain files or paths in a repository.