21 Matching Annotations
- Mar 2021
-
trailblazer.to trailblazer.toTrailblazer15
-
When nesting an activity with multiple outcomes, you can wire each terminus to a different route.
-
For example, an output using Track(:create) will snap to the next possible task that is “magnetic to” :create. That’s how tracks or paths are created.
-
Semantics are mostly relevant for nesting
-
Remember, in a railway activity each task has two standard outputs with the “semantics” success and failure.
-
By using Output(:semantic), you can select an existing output of the task and rewire it.
-
Why don’t we put the “create user” task onto the failure track, and in case of successfully persisting the new user, we deviate back to the happy path?
-
the Activity component is the heart of TRB
-
To implement such an activity, we only need to rewire the second step’s failure output to a new terminus.
-
Since you can reference outputs by their semantic, you as a modeller only connect conceptual termini to ongoing connections!
-
it’s a bit as if the following wiring is applied to every task added via #step
-
Additionally, you may add debugging steps, error handler or rewire the conditions dynamically without touching the original snippet.
-
Suppose that the validate task was getting quite complex and bloated. When writing “normal” Ruby, you’d break up one method into several. In Trailblazer, that’s when you introduce a new, smaller activity.
-
Knowing about the wiring mechanics in Trailblazer is one thing. However, the real fun starts with nesting activities. That’s when the ideas of encapsulation, interfaces and reducing dependencies really come into play.
-
Nesting an activity into another is a bit like calling a library method from another method
-
the explicit modelling has one massive advantage: all possible outcomes of the nested activity are visible and have to be connected in the outer diagram
Tags
- good explanation
- splitting code/component/function into smaller pieces
- good example
- analogy
- good illustration (visual)
- functions
- advantages/merits/pros
- good idea
- semantic meaning
- the Trailblazer way
- see content above
- separation of concerns
- trailblazer-activity: wiring/outputs/tracks
- being explicit
- nesting
- where it shines / best application
- railway-oriented programming
- trailblazer-activity
- main/key/central/essential/core thing/point/problem/meat
- trailblazer-activity: wiring/outputs: semantic
- good point
- Trailblazer
- nice diagram
Annotators
URL
-
-
trailblazer.to trailblazer.to
-
or even configure its taskWrap
-
Please note that the I/O DSL is only providing the most-used requirements. Feel free to use the low-level taskWrap API to build your own variable mapping with different scoping techniques.
-
- Feb 2021
-
trailblazer.to trailblazer.to
-
step :direct_debit
I don't think we would/should really want to make this the "success" (Right) path and :credit_card be the "failure" (Left) track.
Maybe it's okay to repurpose Left and Right for something other than failure/success ... but only if we can actually change the default semantic of those signals/outputs. Is that possible? Maybe there's a way to override or delete the default outputs?
-
Tags
- example: in order to keep example concise/focused, may not implement all best practices (illustrates one thing only)
- trailblazer-activity
- semantics
- I have a question about this
- example: not how you would actually do it (does something wrong/bad/nonideal illustrating but we should overlook it because that's not the one thing the example is trying to illustrate/show us)
- feels wrong
Annotators
URL
-
-
trailblazer.to trailblazer.to
-
Activities are a necessary abstraction on top of Ruby.
-
-
trailblazer.to trailblazer.to
-
An operation has two invocation styles. This is the only difference to an Activity.
-