52 Matching Annotations
  1. Dec 2020
    1. When Sapper renders a page on the server, it will attempt to serialize the resolved value (using devalue) and include it on the page, so that the client doesn't also need to call preload upon initialization.
  2. Nov 2020
    1. If the client JS is disabled, then handleSubmit will never be executed and you have to care that your /api/fakeBackendRoute will handle the data exactly how the client would.
    1. This scenario demonstrates one drawback of CSS: With all the style rules that need to be applied to multiple elements on multiple pages, things can get pretty redundant. And redundancy can eat up your time and cause friction whenever you need to change a color, font, or any other style aspect across your site.
    1. Trapping focus correctly for a modal dialog requires a complex set of events and interaction patterns that we feel is best not duplicated within the logic of this component.
  3. Oct 2020
    1. Please don't copy answers to multiple questions; this is the same as your answer to a similar question

      Why on earth not? There's nothing wrong with reusing the same answer if it can work for multiple questions. That's called being efficient. It would be stupid to write a new answer from scratch when you already have one that can work very well and fits the question very well.

    1. Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
    2. hyperscript is more concise because it's just a function call and doesn't require a closing tag. Using it will greatly simplify your tooling chain.

      I suppose this is also an argument that Python tries to make? That other languages have this con:

      • cons: closing tags make it more verbose / increase duplication and that Python is simpler / more concise because it uses indentation instead of closing delimiters like end or } ?
    1. Other frameworks, which use a template syntax built atop HTML — Svelte, Vue, Ractive, Glimmer etc — have historically been fragmented, meaning those tools need to be reinvented many times.
    1. Note how we have to duplicate the code between these two lifecycle methods in class. This is because in many cases we want to perform the same side effect regardless of whether the component just mounted, or if it has been updated. Conceptually, we want it to happen after every render — but React class components don’t have a method like this. We could extract a separate method but we would still have to call it in two places.
  4. Sep 2020
    1. This leads to web developers at every company needing to rebuild every control from scratch. This represents millions of dollars of investment for each company to duplicate work that many other companies are also doing.
    2. Modern view libraries like React allow teams to build and maintain these components more easily than ever before, but it is still extraordinarily difficult to do so in a fully accessible way with interactions that work across many types of devices.
    1. Part of the functionality that is returned are event handlers. I'd like to avoid needing to manually copy the events over one by one so the hook implementation details are hidden.
    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
    1. Do not include the same information in multiple places. Link to a SSOT instead.
    2. Having a knowledge base in any form that is separate from the documentation would be against the docs-first methodology because the content would overlap with the documentation.
    3. New information that would be useful toward the future usage or troubleshooting of GitLab should not be written directly in a forum or other messaging system, but added to a docs MR and then referenced, as described above.
    4. When you encounter new information not available in GitLab’s documentation (for example, when working on a support case or testing a feature), your first step should be to create a merge request (MR) to add this information to the docs. You can then share the MR in order to communicate this information.
    5. If the answer to a question exists in documentation, share the link to the docs instead of rephrasing the information.
    6. 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
    7. At GitLab, we have so many product changes in our monthly releases that we can’t afford to continuously update multiple types of information. If we have multiple types, the information will become outdated.
  6. Jul 2020
    1. RDFa is intended to solve the problem of marking up machine-readable data in HTML documents. RDFa provides a set of HTML attributes to augment visual data with machine-readable hints. Using RDFa, authors may turn their existing human-visible text and links into machine-readable data without repeating content.
  7. Jun 2020
    1. Duplicated data is a common practice when working with non-relational databases as Firebase. It saves us from performing extra queries to get data making data retrieval faster and easier
  8. May 2020
    1. There are no plans to deprecate the REST API. To reduce the technical burden of supporting two APIs in parallel, they should share implementations as much as possible.
    1. Despite our best efforts to deal with all of those issues, over the course of time we fall behind. When you look at an issue it's sometimes unclear whether or not we intent to provide the functionality you propose, whether or not we fix the bug, whether or not the issue is a duplicate of another one. In order to restore a reasonable level of clarity we annually perform a House Keeping Iteration in which we go through all open issues. We categorize, label, fix, and close issues. This results in a wave of notification which is hard to deal with (our apologies) but in the end there is better understanding of what will happen to your ideas.
    1. This also ties in the "Single Source Of Truth", where even if I craft descriptive commit messages I will probably have to describe what I did in the MR comments anyways, so that feels like duplicate work.
  9. Apr 2020
    1. A miniature / iframe-friendly version of https://www.iubenda.com/en/user/tos/legal?ifr=false

      When you first sign up, it displays this in an iframe as https://www.iubenda.com/en/user/tos?ifr=true&height=680, with an "Accept and continue" button you must click to continue

    1. Running the same code in the browser and on the server in order to avoid code duplication is a very different problem. It is simply a matter of good development practices to avoid code duplication. This however is not limited to isomorphic applications. A utility library such as Lodash is “universal”, but has nothing to do with isomorphism. Sharing code between environments does not give you an isomorphic application. What we’re referring to with Universal JavaScript is simply the fact that it is JavaScript code which is environment agnostic. It can run anywhere. In fact most JavaScript code will run fine on any JavaScript platform.
    1. Also discussed in stackoverflow.com/questions/11003418/…

      Thank you for not just marking it as a duplicate simply because some similar but different question exists.

    1. let page = document.getElementById('buttonDiv');

      duplication: As a result of duplication, they somehow ended with this line being present here but not in the downloadable file which is supposed to have the same contents as the snippet shown here.

      They should have updated their static page generation script/process so that their main document referenced options.js and their generator literally included the contents of the referenced file inline. Then there is no chance of the contents of the inline snippet and downloaded snippet diverging and not matching.

      Evidently, however, the contents of each are managed independently (in other words, there is duplication), easily leading to the contents diverging, as they did.

  10. Mar 2020
    1. Technical cookies, preference, session and optimization cookies;Statistical cookies run by first-party solutions (eg. Matomo/Piwik or other solutions hosted/run by you);Statistical cookies by third parties (eg. Google Analytics), but only where the data is anonymized and is not used for profiling (even indirectly).
    1. Why is the changelog on a separate page and not here? The WordPress.org repository is just another place to download this plugin. I don’t want to maintain too many pages with the same content.
  11. Dec 2019
    1. It's confusing whether one should put things in gemspec development_dependencies or in Gemfile or in both.

      Duplication is bad since the lists could get out of sync. And the gemspec's development_dependencies should be a complete list. Therefore, my opinion is that that should be the canonical list and therefore the only list.

      Actually, what good is gemspec's development_dependencies? A contributor should clone the repo, run bundle, and get the dev dependencies that way. Therefore development_dependencies is unneeded and you should only list them in Gemfile.

      It is simpler to just use Gemfile, since it is a more familiar format. You can copy and paste content into it. For example, if you extract a gem out of an app, you may wan to copy/move some gems from app's Gemfile into new gem's Gemfile. It also generates a Gemfile.lock (which you shouldn't add to git).

    1. Having duplicate code is not ideal. One version of the code may be more up-to-date than another version, creating something similar to a race condition around code versioning. If a bug is found, it would need to be fixed in every place that shares the code while hoping that the developer can remember them all. An inconsistent bug fixing process could multiply bugs and create havoc in a codebase.
  12. Nov 2019
    1. Wow, looks like a lot of duplication in https://github.com/constelation/monorepo/blob/master/packages/Style_/src/index.native.tsx compared to https://github.com/constelation/monorepo/blob/master/packages/Style_/src/index.tsx to handle differences in props on the different platforms such as backfaceVisibility.

      And even structure/shape differences like:

      const style = { ...styleFromProps, ...this.props.style, ...Child.props.style }


          propsToPass.style = [styleFromProps, this.props.style, Child.props.style]

      Is there no way to remove this duplication?