phosphor-signaling
A module for type-safe inter-object communication.
Package Install
Prerequisites
npm install --save phosphor-signaling
Source Build
Prerequisites
git clone https://github.com/phosphorjs/phosphor-signaling.gitcd phosphor-signalingnpm install
Rebuild
npm run cleannpm run build
Run Tests
Follow the source build instructions first.
npm test
Build Docs
Follow the source build instructions first.
npm run docs
Navigate to docs/index.html
.
Supported Runtimes
The runtime versions which are currently known to work are listed below. Earlier versions may also work, but come with no guarantees.
- Node 0.12.7+
- IE 11+
- Firefox 32+
- Chrome 38+
Bundle for the Browser
Follow the package install instructions first.
npm install --save-dev browserifybrowserify myapp.js -o mybundle.js
Usage Examples
Note: This module is fully compatible with Node/Babel/ES6/ES5. Simply omit the type declarations when using a language other than TypeScript.
Recommended Design Patterns:
Class authors should strive to maintain consistency in how their classes expose signals to consumers. The PhosphorJS project has adopted a set of conventions which cover signal naming and exposure. It is recommended for third party libraries to adopt these same conventions in order to ensure API consistency and maximal compatibility with libraries and meta tools which rely on these conventions.
When defining a signal for use by instances of the same class:
-
Define the signal as a static member of the class.
-
Ensure the class type is used as the signal owner type.
-
Append the suffix
'Signal'
to the static member name. -
Define a public getter which binds the static signal to the instance. This getter should contain no logic outside of binding the signal.
-
The name of the getter should be the same as the name of the static signal minus the
'Signal'
suffix. -
Consumers should normally use the getter to access the signal, but meta tools and code generators are free to use the static API directly. This is why the getter must be a pure delegate as described above.
; ;; m1.valueChanged.connectlogger;m2.valueChanged.connectlogger; ;; m1.value = 42; // logs: foo 42, ham 42m2.value = 17; // logs: bar 17, eggs 17
When defining a signal for use by instances of a different class:
-
Define the signal as a static member of the class.
-
Ensure the instance type is used as the signal owner type.
-
Append the suffix
'Signal'
to the static member name. -
Define a static method to get the bound signal for a particular instance of the owner type. This method should contain no logic outside of binding the signal.
-
Name the static method by prepending
'get'
to the capitalized signal name. Omit the'Signal'
suffix. -
Consumers should normally use the static method to access the bound signal, but meta tools and code generators are free to use the static API directly. This is why the method must be a pure delegate as described above.
This pattern is referred to as an attached signal. The signal is defined by one class, but the sender is a foreign instance. This pattern is useful when creating container objects which must emit signals for child objects in a way which doesn't require polluting the child class with extraneous signal definitions.
Auxiliary API:
; // Disconnect a handler from all models in a single-shot.disconnectReceiverhandler; // Disconnect a particular model from all handlers in a single-shot.disconnectSendermodel; // disconnect everything - sender *and* receiverclearSignalDatamodel;