Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-4883

Implement new event type of "latched events" which represent "promise/deferred" type events which may fire only once

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4
    • Fix Version/s: None
    • Component/s: Framework
    • Labels:
      None

      Description

      FLUID-4879 revealed a situation in which the framework required the user to take very different strategies depending on whether an event was expected to be fired synchronously or not. This is generally unacceptable - designers should have ways of being agnostic to these kinds of issues.

      The community at large has a well-defined semantic for this kind of issue, which goes by the name of "promises" or in some communities a "deferred" object. That abstraction covers slightly more than we require here, in that it also comprises the semantic of a "deferred value" which is either available immediately or in the future. What we require here is only the timing semantic portion of this abstraction - that is, an event which is either considered to have "already fired" or will fire in the future.

      Events of this new type would be expected to fire only once during the entire lifetime of the firer. These events would in addition have the special behaviour that if a listener is registered with them at any time AFTER this one event firing has occurred, that listener will be notified immediately on registration. This is in agreement with the behaviour of a "deferred" object, which if "resolved" at any time after its value is available, returns it immediately. Events of this type would be defined with a new RHS value in the listener block, possibly the string "latched". All existing readiness events which match the specification, e.g. all of our lifecycle events (onCreate, onAttach, preInit, etc.), would be converted to this type. We would ensure that any boiling of such events led to events which were also of this type. We might need to directly prohibit boiling of these events together with events of the existing conventional type which might fire multiple times (e.g. onRefresh, onChange etc.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              antranig Antranig Basman
              Reporter:
              antranig Antranig Basman
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated: