23 Matching Annotations
  1. Feb 2021
    1. DSLs can be problematic for the user since the user has to manage state (e.g. am I supposed to call valid? first or update_attributes?). This is exactly why the #validate is the only method to change state in Reform.
    2. The reason Reform does updating attributes and validation in the same step is because I wanna reduce public methods. This is to save users from having to remember state.

      I see what he means, but what would you call this (tag)? "have to remember state"? maybe "have to remember" is close enough

      Or maybe order is important / do things in the right order is all we need to describe the problem/need.

  2. Jan 2021
  3. Dec 2020
  4. Nov 2020
    1. We expect a certain pattern when validate devtool name, pay attention and dont mix up the sequence of devtool string. The pattern is: [inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map.
  5. Oct 2020
    1. Yeah I see what you're saying. In my case, I had a group of classes that relied on each other but they were all part of one conceptual "module" so I made a new file that imports and exposes all of them. In that new file I put the imports in the right order and made sure no code accesses the classes except through the new interface.
    1. Doing so also means adding empty import statements to guarantee correct order of evaluation of modules (in ES modules, evaluation order is determined statically by the order of import declarations, whereas in CommonJS – and environments that simulate CommonJS by shipping a module loader, i.e. Browserify and Webpack – evaluation order is determined at runtime by the order in which require statements are encountered).

      Here: dynamic loading (libraries/functions) meaning: at run time

    2. Specifically, since Root, Rule and AtRule all extend Container, it's essential that Container is evaluated (and therefore, in the context of a Rollup bundle, included) first. In order to do this, input.js (which is the 'gateway' to all the PostCSS stuff) must import root.js, root.js must import rule.js before it imports container.js, and rule.js must import at-rule.js before it imports container.js. Having those imports ensures that container.js doesn't then try to place Root, Rule or AtRule ahead of itself in the bundle.
    3. Replaced nested `require` statements with `import` declarations for the sake of a leaner bundle. This entails adding empty imports to three files to guarantee correct ordering – see https://github.com/styled-components/styled-components/pull/100
    1. Note that the <WarningEngine/> component must be at the bottom of the form to guarantee that all the fields have registered.
  6. Sep 2020
    1. let:hovering={active}

      It seems like it should be the other way around:


      to make it look like a regular let assignment.

      It's only when you consider what/how let:hovering on its own means/works that it makes a bit more sense that it is the way it is. When it's on its own, it's a little clearer that it's saying to "make use of" an available slot prop having the given name. (Very much like bind, where the LHS is also the name of the prop we're getting the data from.) Obviously we have to identify which prop we're wanting to use/pull data from, so that seems like the most essential/main/only thing the name could be referring to. (Of course, as a shortcut (in this shorthand version), and for consistency, it also names the local variable with the same name, but it wouldn't have to.)

      Another even simpler way to remember / look at it:

      1. Everything on the left hand of an prop/attribute [arg] corresponds to something in the component/element that you're passing the [arg] to. Usually it's a prop that you're passing in, but in this case (and in the case of bind:) it's more like a prop that you're pulling out of that component, and attaching to. Either way, the name on the LHS always corresponds to an export let inside that named component.
      2. Everything on the right side corresponds to a name/variable in the local scope. Usually it passes the value of that variable, but in the case of a let: or bind: it actually "passes the variable by reference" (not the value) and associates that local variable with the LHS (the "remote" side).

      Another example is bind: You're actually binding the RHS to the value of the exported prop named on the LHS, but when you read it (until you get used to it?) it can look like it's saying bind a variable named LHS to the prop on the RHS.

  7. Jul 2020
    1. The meta charset information must also be the first child of the <head> tag. The reason this tag must be first is to avoid re-interpreting content that was added before the meta charset tag.

      But what if another tag also specified that it had to be the first child "because ..."? Maybe that hasn't happened yet, but it could and then you'd have to decide which one truly was more important to put first? (Hopefully/probably it wouldn't even matter that much.)

  8. May 2020