6 Matching Annotations
  1. Mar 2021
    1. The reason Final Form does this is so that pristine will be true if you start with an uninitialized form field (i.e. value === undefined), type into it (pristine is now false), and then empty the form field. In this case, pristine should return to true, but the value that the HTML DOM gives for that input is ''. If Final Form did not treat '' and undefined as the same, any field that was ever typed in would forever be dirty, no matter what the user did.
  2. Feb 2021
    1. 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. Oct 2019
    1. There are many strings which I need to convert if not undefined. I could do as follows: { date1: date1 ? formatISODate(date1) : undefined, date2: date2 ? formatISODate(date2) : undefined ...