WEBVTT

00:00:00.700 --> 00:00:07.185
The pipe operator lets us read a sequence of transformations in the order that data travels.

00:00:07.335 --> 00:00:13.842
Our example starts with text that has extra spaces and ends with a clean uppercase message.

00:00:13.992 --> 00:00:20.413
We will write the same work as ordinary calls, named intermediate values, and a pipeline.

00:00:20.563 --> 00:00:22.974
These forms help explain each other.

00:00:23.124 --> 00:00:30.641
The purpose is readable composition, so keep the intermediate types in mind instead of treating the pipe

00:00:30.641 --> 00:00:32.852
as punctuation that works everywhere.

00:00:35.000 --> 00:00:38.520
Start with function calls you can already recognize.

00:00:38.670 --> 00:00:41.763
Trim receives raw text and returns cleaned text.

00:00:41.913 --> 00:00:45.753
Upper receives that result and returns uppercase text.

00:00:45.903 --> 00:00:48.143
Print displays the final value.

00:00:48.293 --> 00:00:54.373
Each binding makes one stage visible and gives you a convenient place to inspect a problem.

00:00:54.523 --> 00:01:00.795
This expanded form is a useful debugging tool even when the final script uses pipes.

00:01:00.945 --> 00:01:07.047
If a long expression is confusing, give its stages names before changing its logic.

00:01:09.200 --> 00:01:14.811
Now place the starting value at the top and put one operation on each following line.

00:01:14.961 --> 00:01:18.694
The output from one stage becomes the input to the next.

00:01:18.844 --> 00:01:21.831
The result should match the ordinary calls exactly.

00:01:21.981 --> 00:01:26.759
This layout becomes especially helpful when a script describes a workflow.

00:01:26.909 --> 00:01:31.027
Read it as raw text, then trim, then uppercase, then print.

00:01:31.177 --> 00:01:38.087
The pipe changes how we write the composition; it does not remove the functions or their input

00:01:38.087 --> 00:01:38.494
requirements.

00:01:40.640 --> 00:01:43.541
A pipe call can also include arguments.

00:01:43.691 --> 00:01:51.129
In this example the piped text fills the first argument of tag, and the explicit prefix supplies the next

00:01:51.129 --> 00:01:51.521
argument.

00:01:51.671 --> 00:01:57.772
Compare the equivalent ordinary call, tag with HHY first and Language second.

00:01:57.922 --> 00:02:02.018
Defining this tiny function makes the argument order visible.

00:02:02.168 --> 00:02:09.460
When using an unfamiliar built in function, read its signature instead of guessing which position a piped

00:02:09.460 --> 00:02:10.317
value occupies.

00:02:12.470 --> 00:02:18.635
At this point every transformation returns a string, so the chain has a straightforward shape.

00:02:18.785 --> 00:02:23.863
Capture the value before printing if you want to reuse it or inspect its type.

00:02:24.013 --> 00:02:31.221
Print is an output operation and returns null; it is not a string transformation to place casually in the

00:02:31.221 --> 00:02:32.738
middle of this chain.

00:02:32.888 --> 00:02:35.469
Track the returned value at each boundary.

00:02:35.619 --> 00:02:42.510
A readable pipeline depends on compatible stages, not only on attractive vertical formatting.

00:02:44.660 --> 00:02:47.220
A named function works as a stage too.

00:02:47.370 --> 00:02:54.251
Announce receives the cleaned text and adds a prefix, while the earlier functions remain responsible for

00:02:54.251 --> 00:02:55.541
whitespace and case.

00:02:55.691 --> 00:03:01.600
Keeping those responsibilities small makes the chain easy to reorder when that is meaningful.

00:03:01.750 --> 00:03:07.915
Here moving announce before upper would also uppercase the prefix, producing a different result.

00:03:08.065 --> 00:03:10.156
Composition is ordered work.

00:03:10.306 --> 00:03:17.517
Before rearranging stages, consider whether each transformation changes what later stages receive.

00:03:19.670 --> 00:03:26.926
A pipe does not automatically make every value a stream in our tested one point seven point zero

00:03:26.926 --> 00:03:27.329
examples.

00:03:27.479 --> 00:03:31.959
For a list transformation, introduce stream explicitly before map.

00:03:32.109 --> 00:03:37.378
Map produces another stream, and collect consumes it into a list that we print.

00:03:37.528 --> 00:03:40.408
We will examine laziness in the next lesson.

00:03:40.558 --> 00:03:45.465
For now, observe the types: list to stream, transformed stream to list.

00:03:45.615 --> 00:03:49.369
The connecting operator cannot replace those conversions.

00:03:51.520 --> 00:03:54.997
The separate error example deliberately omits stream.

00:03:55.147 --> 00:04:00.331
On the tested runtime, map expects a stream and rejects this list input.

00:04:00.481 --> 00:04:07.031
The repair is to insert the explicit conversion, not to change the arithmetic inside the closure.

00:04:07.181 --> 00:04:14.082
When a pipeline fails, inspect the boundary mentioned in the diagnostic: what did the previous stage

00:04:14.082 --> 00:04:17.101
return, and what does this stage require?

00:04:17.251 --> 00:04:21.944
This approach scales much better than replacing several operations at once.

00:04:24.090 --> 00:04:30.298
For practice, write the announcement pipeline and an equivalent version using ordinary calls.

00:04:30.448 --> 00:04:33.093
Run both and verify the same result.

00:04:33.243 --> 00:04:38.427
Then move the announcement step before uppercase and explain the changed prefix.

00:04:38.577 --> 00:04:43.783
Finally, inspect the list example and name the value type after each stage.

00:04:43.933 --> 00:04:51.015
Once you can explain those boundaries, you are ready for streams: pipelines whose elements are pulled

00:04:51.015 --> 00:04:54.557
lazily and whose consumption must be planned deliberately.