19 Matching Annotations
  1. Last 7 days
  2. Oct 2020
    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.
  3. Sep 2020
    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.
  4. 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.
  5. 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.
  6. 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.
  7. Apr 2020
    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.
  8. Mar 2020
    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.
  9. 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).