3 Matching Annotations
  1. May 2019
    1. But like its usual in the case of Observable-based APIs, FRP techniques can help easily implement many use cases that would otherwise be rather hard to implement such as: pre-save the form in the background at each valid state, or even invalid (for example storing the invalid value in a cookie for later use) typical desktop features like undo/redo

      key point on why FRP is good: misc usages on each 'state' change in the form - record and save state for 'undo' feature, save to local storage to be recovered later, etc

    2. This is why this is called template-driven forms, because both validation and binding are all setup in a declarative way at the level of the template.

      key point on naming of 'template-driven forms'

    3. You are probably wondering what we gained here. On the surface there is already a big gain: We can now unit test the form validation logic

      key point - advantage of reactive forms is the testability of its validation