43 Matching Annotations
  1. Jun 2021
    1. -- The array on the right side is not considered contained within the -- array on the left, even though a similar array is nested within it: SELECT '[1, 2, [1, 3]]'::jsonb @> '[1, 3]'::jsonb; -- yields false -- But with a layer of nesting, it is contained: SELECT '[1, 2, [1, 3]]'::jsonb @> '[[1, 3]]'::jsonb;
    1. We need to be really careful about what's 'same origin' because the server has no idea what host/path the various cookies are associated with. It just has a list of cookies that the browser had determined to be relevant for this SSR'd page, and not for any other subrequests.
  2. Apr 2021
  3. Mar 2021
    1. Dictionary writers list polysemes under the same entry; homonyms are defined separately.

      This describes how you can tell which one it is by looking at the dictionary entry.

    2. Polysemy is thus distinct from homonymy—or homophony—which is an accidental similarity between two words (such as bear the animal, and the verb to bear); while homonymy is often a mere linguistic coincidence, polysemy is not.
    1. Generally, CSS selectors refer to markup or, in some cases, to element properties as set with scripting (client-side JavaScript), rather than user actions. For example, :empty matches element with empty content in markup; all input elements are unavoidably empty in this sense. The selector [value=""] tests whether the element has the value attribute in markup and has the empty string as its value. And :checked and :indeterminate are similar things. They are not affected by actual user input.
    2. The selector [value=""] tests whether the element has the value attribute in markup and has the empty string as its value.
  4. Feb 2021
    1. Using Track() with a new track semantic only makes sense when using the [:magnetic_to option] on other tasks.
    1. If any of the inputs are invalid, #execute won't be run.

      It does staged/pipelined execution/validation.

      If any of these stages has any errors, then no other stages will be executed:

      1. validations on the inputs of the interaction itself
      2. run execute, which may:
      3. may use compose, which will (IIUC) abort the entire execute/run early if any of them fail, even if there are later composed interactions still to be run
      4. may try to save inputs into models, which themselves may have validation errors, which (assuming we use errors.merge), will show up on the interaction.errors (but won't abort the rest of the execute)
    2. There are times where it is useful to know whether a value was passed to run or the result of a filter default. In particular, it is useful when nil is an acceptable value.

      Yes! An illustration in ruby:

      main > h = {key_with_nil_value: nil}
      => {:key_with_nil_value=>nil}
      
      main > h[:key_with_nil_value]
      => nil
      
      main > h[:missing_key]  # this would be undefined in JavaScript (a useful distinction) rather than null, but in Ruby it's indistinguishable from the case where a nil value was actually explicitly _supplied_ by the caller/user
      => nil
      
      # so we have to check for "missingness" ("undefinedness"?) differently in Ruby
      
      main > h.key?(:key_with_nil_value)
      => true
      
      main > h.key?(:missing_key)
      => false
      

      This is one unfortunate side effect of Ruby having only nil and no built-in way to distinguish between null and undefined like in JavaScript.

    3. When you run this interaction, two things will happen. First ActiveInteraction will type check your inputs. Then ActiveModel will validate them. If both of those are happy, it will be executed.

      Failed type checks generate run-time errors. So it's up to the develop to fix these, permanently, since the user can't (99% of time) do anything to fix these.

      Failed validations add errors to interaction.errors object. These are for the user to fix.

  5. Jan 2021
    1. Blocks Don’t Need 100% Width When we understand the difference between block-level elements and inline elements, we’ll know that a block element (such as a <div>, <p>, or <ul>, to name a few) will, by default expand to fit the width of its containing, or parent, element (minus any margins it has or padding its parent has).
  6. Nov 2020
    1. this in particular comes from the addressee

      I think the ruling's main point/distinction here is that while submitting a form might be getting consent from the addressee (the person submitting form might be the addressee, if they own the e-mail address they entered), but we can't know that for sure until they confirm by clicking a link in the e-mail.

      Only then do we know for sure that the actor submitting the form was the addressee and that the consent ostensibly received via the form was in fact from the addressee. But it could otherwise be the case that they entered someone else's address, and you can't give consent on behalf of someone else!

  7. Oct 2020
    1. For performance reasons, $: reactive blocks are batched up and run in the next microtask. This is the expected behavior. This is one of the things that we should talk about when we figure out how and where we want to have a section in the docs that goes into more details about reactivity. If you want something that updates synchronously and depends on another value, you can use a derived store:
    1. The clean-up function runs before the component is removed from the UI to prevent memory leaks. Additionally, if a component renders multiple times (as they typically do), the previous effect is cleaned up before executing the next effect. In our example, this means a new subscription is created on every update.
    1. The readable store takes a function as a second argument which has its own internal set method, allowing us to wrap any api, like Xstate or Redux that has its own built in sub­scrip­tion model but with a slightly different api.
  8. Sep 2020
    1. Auto-subscription only works with store variables that are declared (or imported) at the top-level scope of a component.
    1. feel like there needs to be an easy way to style sub-components without their cooperation
    2. 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. Notice that all tags start with a lower case letter. This is different to other NativeScript implementations. The lower case letter lets the Svelte compiler know that these are NativeScript views and not Svelte components. Think of <page> and <actionBar> as just another set of application building blocks like <ul> and <div>.
  9. Aug 2020
    1. Co-hyponyms are labelled as such when separate hyponyms share the same hypernym but are not hyponyms of one another, unless they happen to be synonymous
    1. Note that the double quotes around "${arr[@]}" are really important. Without them, the for loop will break up the array by substrings separated by any spaces within the strings instead of by whole string elements within the array. ie: if you had declare -a arr=("element 1" "element 2" "element 3"), then for i in ${arr[@]} would mistakenly iterate 6 times since each string becomes 2 substrings separated by the space in the string, whereas for i in "${arr[@]}" would iterate 3 times, correctly, as desired, maintaining each string as a single unit despite having a space in it.
  10. May 2020
    1. It may be the case that several sufficient conditions, when taken together, constitute a single necessary condition (i.e., individually sufficient and jointly necessary)