66 Matching Annotations
  1. Sep 2023
    1. make_a_class::CONST = 42.tap { puts "Calculating the value" } # Prints: # In Ruby 3.1: # Calculating the value # Making a class # In Ruby 3.2: # Making a class # Calculating the value # Even simpler: NonExistentModule::CONST = 42.tap { puts "Calculating the value" } # Ruby 3.1: # Prints "Calculating the value" # raises "uninitialized constant NonExistentModule" (NameError) # Ruby 3.2: # just raises "uninitialized constant NonExistentModule" (NameError)
  2. Oct 2021
  3. Jan 2021
  4. Oct 2020
    1. This would be like an executable proposal. I understand that it's beyond the original intent of having canonical patterns on the Svelte site, but it would facilitate the community to express their own patterns. Now that we have markdown preprocessors , the documentation itself can be an app.
  5. Sep 2020
    1. Proving to myself that isValid does correctly change to true even when a key in $errors is an array.

    1. Child can't update things by reassignment if you do:

      <Child bind:things={things} />

      but can if you do;

      <Child bind:things={$object.things} />
    1. Demonstrates that even though object.value kind of works, it will be out of date. You need to subscribe to it to get current value: $object.value

  6. Aug 2020
    1. This illustrates the difference between two types of scrolling:

      • scrolling within the dialog
      • scrolling the document that includes the dialog
  7. May 2020
  8. Dec 2019
  9. Nov 2019
  10. Oct 2019
  11. Sep 2019
  12. Aug 2019
    1. Demonstrates how label text will wrap at a point that appears to narrow when shrunk (the label can't even be as wide as the input it is labeling!), and how to work around this problem by adding styles:

        '& label': {
          whiteSpace: 'nowrap'

      Of course, you would only want to do this if you are going to only be showing the label in shrunk state (which I think is safe to say is the case for date picker inputs), since it would look bad to actually have text overflowing outside of the input box. But if it's in "shrink" state, then it's actually above the input, so as long as there isn't another input/label directly to the right, and/or as long as we adjust the width so the right side of the label mostly lines up with the right side of the input, then I think we should be safe.


      The input label "shrink" state isn't always correct. The input label is supposed to shrink as soon as the input is displaying something. In some circumstances, we can't determine the "shrink" state (number input, datetime input, Stripe input). You might notice an overlap.

      To workaround the issue, you can force the "shrink" state of the label.

      You need to make sure that the input is larger than the label to display correctly.