 Courses from Paul Frend

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

Our helpers are now powerful enough to work with any data type as the source, but they can only build up arrays or objects as the target. For an arbitrary collection type, we thus have to fall back to our `transduce` function and manually specify the inner reducer behavior based on the API of our target collection. 

In this lesson, we'll add support for the transducer protocol, and see how it enables us to transduce into any collection type without having to fall back to using `transduce`. We'll use the `List` type from [Immutable.JS](https://facebook.github.io/immutable-js/) as our example.

Add the Transducer Protocol to Support Arbitrary Data Types as our Target Collections

Our `transduce` function is powerful but requires a lot of boilerplate.
It would be nice if we had a way to transduce into arrays and objects without having to specify the inner reducer behaviour, i.e. how to build up values, since a given collection type will almost always have the same inner reducer.

In this lesson we'll being doing just that with an `into()` helper function that will know if an array or object collection is passed in and handle each case accordingly. 

Make an Into Helper to Remove Boilerplate and Simplify our Transduce API

So far we've been transducing by manually calling `.reduce()` on arrays, but we want to be able to transduce over other collection types as well.

In this lesson we'll create a `transduce` function to support transducing over any data structure that implements the [es2015 iterable protocol](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols). We’ll put it to the test by transducing over strings and maps, as well as going from one collection type as input to another as output.

Transduce over any Iteratable Collection

To make our composition more readable and easier to name we are going to ceate a `compose` function we can use to avoid having to manually nest our transducer calls. 

We'll also go over semantically naming your `compose` functions for extra readability. 


Improve Composition with the Compose Combinator

A frequent use case when transducing is to apply a transformation to items without changing the type of the collection.

In this lesson, we'll create a helper to do just that. `seq` will be similar to `into`, except the target type will be inferred from the source collection. For example, if transducing from an array, `seq` will create an array as the output collection as well.

`seq` is thus more restrictive and easier to consume than `into`.

Create a Sequence Helper to Transduce Without Changing Collection Types

We've seen how we can `transduce` from arrays or other iterables, but plain objects aren't iterable in Javascript.
In this lesson we'll modify our `transduce()` function so that it supports iterating from plain objects as well, treating each key value pair as an entry in the collection.

To do this we'll be using a **lodash** function called [entries](https://lodash.com/docs/4.17.4#toPairs). 

Transduce When the Collection Type is an Object

While it’s possible to use our transducers in production (after writing some tests!), I would recommend using a proven transducer library instead.

In this lesson, we’ll go through how to use [transducers.js](https://goo.gl/QpWAwT) from [James Long](https://goo.gl/e4Jtsr) instead of our functions. We’ll also cover some more advanced features which we didn't add support for ourselves, like short-circuiting iterations with the `take` transform as well as transducing lazily over iterables.

The aim is that you’ll be able to use these libraries with more confidence and better understanding since we’ve been through how things are working under the hood.

You can also check out [transducers-js](https://github.com/cognitect-labs/transducers-js) by [cognitect labs](https://github.com/cognitect-labs), which is very similar in its feature set to transducers.js.
And remember, you don’t have to rely solely on the transforms in the library, you can write your own as well, as long as you support the transducer protocol.

Use Transducers in Production

In our previous lesson, we created `map()` and `filter()` functions based on reduce, but we still couldn’t compose them together.

In this lesson, we’ll solve this by making these functions into transducers. This will let us compose the reducing behavior of `map()` and `filter()`, without coupling this composed transform to a data type.

Create Map and Filter Transducers

Two of the most useful operators when working with collections are `.map()` and `.filter()`. We want our **transducers** to be able to combine these operations in a single pass when iterating through our collections. To do this we need to find a commonality between the two, so we can treat them the same. To achieve this common ground, we'll create `map()` and `filter()` functions which use the built in `.reduce()` function under the hood instead, and we’ll start to combine the concepts of transforming and reducing.

Rewrite Map and Filter as Reducers

Now that our transducer functions are functioning as expected, it’s time for another round of performance testing.
We’ll use the same `timeIt()` function from [Lesson One](https://egghead.io/lessons/javascript-understand-why-transducers-can-improve-performance) to see how our transducers compare to the Array built-in methods, an imperative solution, as well as the external transducer library [transducers.js](https://github.com/jlongster/transducers.js?files=1).


Measure the Performance of our Transducers

Now that we understand the problem transducers can help us with, it's time to define what they actually are.
A Transducer is a combination of two concepts, a *transform*, and a *reducer*. **Trans-Ducer**.
In this lesson we'll give a general overview of the *reducer* part of the puzzle. 


Write Reducers for Different Data Types


The next transducer building block we need to explore is a **transformer**. A transformer is a function that takes a value and returns a transformed version of it.

In this lesson, we cover some examples of transformer functions and use them with some basic composition. We'll follow the functional style of creating new values, avoiding mutations. Even though they're trivial functions, it's important to understand how they work, as soon we’ll be combining them with reducers to create transducers. 

Understand Transformer Functions

Chaining operations like `map` and `filter` on an array can have performance issues as we have to iterate through the whole array for every operation.

In this lesson we explore this problem by doing some basic array transformations and measuring their performance.

 We’ve got two utility function to help us with this:
* `arrayOfRandoms` is a higher order function which helps us create a range of random numbers
* `timeIt` will help us measure how long functions take to execute

It's important to understand this problem and why it occurs before we move on to how transducers handle it differently.

Understand why Transducers can Improve Performance

In this course, we will go through the concept of transducers and build them up from basic principles. We will go over the problems with regular composed transformations, and show how we end up with unnecessary data and intermediate collections. We go on to learn how we can use transducers for performance gains when operating on large data sets, as well as how they’re an excellent fit for processing other iterable data, like generators. Not just arrays.

Quickly Transform Data with Transducers

A modern JavaScript utility library delivering modularity, performance & extras.

lodash

Imagine if looking at your business logic read as simple as a story from a children's book. That's exactly what we'll cover by learning how to compose small pieces of business logic and also set them up for further composition in the future.

We're showing a list of fictional tweets in a trivial React component created with create-react-app, however the example is not React specific and can be applied to any framework/environment.

Our example will refactor out business logic from a non-composable function to small composable pieces. To accomplish this we'll be using flow, filter and map from lodash/fp, which is included in the regular lodash npm package.

This approach works well in any environment where you're not relying on object references to your original data, as our functional approach creates new collection objects instead of mutating them.

Guide to lodash/fp: https://github.com/lodash/lodash/wiki/FP-Guide


Refactor Business Logic to Composable Functions with Lodash

Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments.



Mocking WebSocket APIs with Mock Service Worker


When attempting to load the same module twice in JavaScript you'll hit a cache and code won't re-run. In scenarios where you actually do want to have state in your modules, you'll have to use a cache-busting technique by passing a query parameter to a dynamic import. This lesson walks through how to add a query parameter, how to add the appropriate types for loading dynamic modules in TypeScript, and when these techniques are valuable.

Import the Same JavaScript Module Multiple Times with Cache Busting



The include keyword in GitHub Actions empowers you to add custom variables to your matrix strategy, providing flexibility beyond standard configurations. In this video, we'll explore how include allows you to define specific combinations of variables, enhancing control over your workflow runs. You'll see how this feature enables you to tailor jobs for unique environments or scenarios not covered by the default matrix options. By leveraging include, you can efficiently manage complex build processes with greater precision. This technique helps you streamline your CI/CD pipeline, making it more adaptable to your project's evolving needs.

Use GitHub Actions Matrix Include for Complex Job Configurations

While running `zod` schema validation agains domain-rich objects, the error message saying that _a string is not a number_ might not be really useful.

Especially, when you need to provide a meaningful feeback to the user, e.g. after they have submitted a form with lots of data.

`zod` allows to customize messages on a very granular level. We can also extract repeatable customization to `zod` error maps.

Finally, in order to process an error message further (e.g. display it to the user), we need to handle the `zod` validation errors effectively. Especially, when a big object validation has failed and we could receive a handful of errors.

That's what we learn in this lesson. 🔥

Customize zod Error Messages and Handle zod Errors Effectively

customize zod validation messages, customize zod schema property messages, reuse error maps across different schemas, navigate through zod error objects

You might want to run `zod` schema checks in different styles.

Sometimes you prefer to conditionally throw the error - that's what `parse` does. But another time you'd prefer to receive a `boolean` property that determines whether the validation was successful or not - and perform further actions accordingly.

Additionally, the error-throwing API of `parse` works extremely well with [TypeScript assertion functions](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions). Their combination is just... perfect! 👌

That's what we learn in this lesson.

Use parse and safeParse Runtime Type-checks with zod

use zod parse function to conditionally throw ZodError, use zod safeParse to get a boolean value and run typescript type guard over success property

In this lesson we learn that TypeScript cannot guarantee correct shapes of responses. That's due to TS performing checks in compile-time, while the response will be availbale in runtime - when TS doesn't exist anymore.

In some situations, such as HTTP requests, runtime type checks such as `zod` are essential for providing quick feedback around data-related errors.

Understand where are the possible mistakes to make while using TypeScript with HTTP calls. Use `fetch` and `axios` along with `zod` schema checks.

Also, note that similar mistakes or mistakes could happen while using web storage (e.g. `localStorage`)

Validate HTTP API Response with zod, fetch and axios

use zod as an HTTP response validation tool along with fetch and axios in order to make sure that the response has expected data structure

In this lesson we learn that the `zod` schemas become the single source of truth.

We shall not update TypeScript types manually, since they are generated automatically from the schema.

Same with validation functions.

Whenever the schema changes, all the rest will update accordingly. It's an important mind shift.

Treat zod Schemas as Single Source of Truth

Zod Schemas are the single source of truth for both typescript types, and interfaces - and runtime validation functions. Schemas should be updated first.

`zod` is powerful, but writing the schemas manually for existing JSON objects, especially big ones, can be time-consuming.

But that's what `quicktype` is for! You can get 80% work done instantly! 🥳

Depending on your need - whether you want to automate the process, or do it just one time, you can:
- use an online app
- use an IDE extension
- run a CLI script
- generate a script to be executed within CI/CD environment/tooling

And this is what we learn in this lesson! 🔥🔥🔥

Get started with zod quickly!

Generate zod Schemas Automatically using Quicktype App, Extensions and Scripts

Use quicktype app, extension or scripts to automatically generate zod schemas from existing json files. Save time and get started with zod quickly!

`zod` is a powerful library allowing to run runtime type-checks.

It's complementary to TypeScript, which does type checks in compile time.

In this lesson we create few schemas that represent primitive type values, along with `zod` utilities which make these more precise. We also create object schemas and nest one inside another.

All schemas are being validated against example values. We analyze how to interpret error messages in case of failures.

Perform Runtime Type-checks on Primitives and Objects with zod

Create zod schemas to validate primitive type and object type values in runtime. Analyze the errors to see how a value doesn't correspond to schema expectations


Using Cursor Chat, you can easily reference an entire directory of files and ask it to generate anything based on those files. This opens up the possibility of using your current code as a reference guide to create new code that follows existing patterns. With this approach, the result can be a polished prompt you can use with any AI to generate consistent and reliable output.

Focus less on crafting the perfect prompt upfront - what matters most is testing and iterating based on the AI's responses. The more results you see from the prompt, the more you can reinforce the good results and prune out the bad results until your prompt is polished enough that you can rely on the prompt to give you consistent quality results.


Paul Frend

Search Results