Angular

Free Angular Training during JavaScript Marathon with This Dot Labs

Mar 26, 2020

4 min read

Now that we're all working from home, This Dot Labs has something planned to keep you tied up - online Angular training!

In celebration of our new remote, corporate training offerings, This Dot invites you to enjoy six weeks of free, live Angular courses!

This is just one of the five weekly sessions we're hosting on topics, including Vue, React, RxJS, and Web Performance!

You can sign up for other courses and find the full schedule at JavaScriptMarathon.com.

Enjoy 6 free Angular courses, given LIVE every Wednesday the entire month of April! Sign up below.

April 1, 2020: 1 Hour to Learn Angular

This is an introduction to Angular. We will walk through what the Angular CLI is, and how it can help us. We’ll explore a newly created Angular application, as well as data binding (interpolation, attribute vs property bindings, class bindings), and components using input and outputs. We will introduce a service to fetch async data as well as a custom pipe to render data differently from the underlying model. We will do this using the Angular CLI to show the participants how much is done for them. Last but not least, we will add some custom CSS to ensure everything looks as pretty as possible.

April 8, 2020: The Best Pro Tips for A11Y in Angular

In this training you’ll learn how to make your Angular applications more accessible. We’ll teach you what NOT to do, and provide you with some best practice tips on what to do to ensure accessibility compliance.

April 15, 2020: Master PWA in Angular

In this training, you will learn how easy it is to convert your Angular application into a PWA with just one command. We’ll also dive into the files generated by the Angular CLI that make your application a PWA, and help you better understand what Angular is doing under the hood.

April, 22, 2020: Advanced NgRx: Complex Angular State Management

State management libraries like NgRx can be simple to learn, but difficult to master. Managed correctly, NgRx can be a powerful tool for isolating complexity and separating concerns, greatly speeding up development, and reducing errors. However, when applied incorrectly, NgRx can overwhelm your team and actually worsen errors. Luckily, there are a handful of tips that can help you, and your team, reach state management bliss. In this training, we’ll discuss event-based actions, event storming, how to write more resilient effects, how to determine what data belongs in your store, how to build more maintainable selectors and components, and how to identify when your team is heading down the wrong path. NOTE: This training expects that attendees already know the basics of the NgRx architecture (selectors, reducers, actions, and effects)

April 29, 2020: Easy Angular Unit Testing in NgRx

NgRx is awesome, but testing can be a complex job. We’ll cover some of the common patterns to test NgRx’s reducers, selectors, effects as well as components that are using those selectors and actions. We will also cover a bit of marble testing as well to help you along in your testing journey.

May 6, 2020: A Guide to Advanced Angular Patterns (Route Guards, Pipes, Interceptors, and more)

It’s easy to write websites and applications in Angular using mostly basic components, services, and the built-in Angular tools (such as pipes). But, there’s a lot more you can do in Angular to build your own utilities, and extend the Angular platform! In this training, we’ll learn how to take full advantage of the Angular platform. We’ll explain and build sample route guards, pipes, interceptors, and directives. Along the way, we’ll call out some common pitfalls that trip up teams as they start to build their own utilities.

You can RSVP to attend any of these amazing events, hosted by talented team members at This Dot Labs, by clicking on the hyperlinks above! If you have any questions, or want to learn more about the JavaScript Marathon series, visit javascriptmarathon.com, or email us at hi@thisdot.co.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

This Dot

How to create and use custom GraphQL Scalars

How to create and use custom GraphQL Scalars In the realm of GraphQL, scalars form the bedrock of the type system, representing the most fundamental data types like strings, numbers, and booleans. As explored in our previous post, "Leveraging GraphQL Scalars to Enhance Your Schema," scalars play a pivotal role in defining how data is structured and validated. But what happens when the default scalars aren't quite enough? What happens when your application demands a data type as unique as its requirements? Enter the world of custom GraphQL scalars. These data types go beyond the conventional, offering the power and flexibility to tailor your schema to precisely match your application's unique needs. Whether handling complex data structures, enforcing specific data formats, or simply bringing clarity to your API, custom scalars open up a new realm of possibilities. In this post, we'll explore how to understand, create, and effectively utilize custom scalars in GraphQL. From conceptualization to implementation, we'll cover the essentials of extending your GraphQL toolkit, empowering you to transform abstract ideas into concrete, practical solutions. So, let's embark together on the journey of understanding and utilizing custom GraphQL scalars, enhancing and expanding the capabilities of your GraphQL schema. Understanding Custom Scalars Custom scalars in GraphQL extend beyond basic types like String or Int, allowing data to be defined, validated, and processed more precisely. They're instrumental when default types don't quite capture the complexity or specificity of the data, such as with specialized date formats or unique identifiers. The use of custom scalars brings several benefits: * Enhanced Clarity: They offer a clearer representation of what data looks like and how it behaves. * Built-in Validation: Data integrity is bolstered at the schema level. * Flexibility: They can be tailored to specific data handling needs, making your schema more adaptable and robust. With this understanding, we'll explore creating and integrating custom scalars into a GraphQL schema, turning theory into practice. Creating a Custom Scalar Defining a Custom Scalar in TypeScript: Creating a custom scalar in GraphQL with TypeScript involves defining its behavior through parsing, serialization, and validation functions. * Parsing: Transforms input data from the client into a server-understandable format. * Serializing: Converts server data back to a client-friendly format. * Validation: Ensures data adheres to the defined format or criteria. Example: A 'Color' Scalar in TypeScript The Color scalar will ensure that every color value adheres to a valid hexadecimal format, like #FFFFFF for white or #000000 for black: ` In this TypeScript implementation: * validateColors: a function that checks if the provided string matches the hexadecimal color format. * parseValue: a method function that converts the scalar’s value from the client into the server’s representation format - this method is called when a client provides the scalar as a variable. See parseValue docs for more information * serialize: a method function that converts the scalar’s server representation format to the client format, see serialize docs for more information * parseLiteral: similar to parseValue, this method function converts the scalar’s value from the client to the server’s representation format. Still, this method is called when the scalar is provided as a hard-coded argument (inline). See parseLiteral docs for more information In the upcoming section, we'll explore how to incorporate and validate these custom scalars within your schema, ensuring they function seamlessly in real-world scenarios. Integrating Custom Scalars into a Schema Incorporating the 'Color' Scalar After defining your custom Color scalar, the next crucial step is effectively integrating it into your GraphQL schema. This integration ensures that your GraphQL server recognizes and correctly utilizes the scalar. Step-by-Step Integration 1. Add the scalar to Type Definitions: Include the Color scalar in your GraphQL type definitions. This inclusion informs GraphQL about this new scalar type. 2. Resolver Mapping: Map your custom scalar type to its resolver. This connection is key for GraphQL to understand how to process this type during queries and mutations. ` 1. Use the scalar: Update your type to use the new custom scalar ` Testing the Integration With your custom Color scalar integrated, conducting thorough testing is vital. Ensure that your GraphQL server correctly handles the Color scalar, particularly in terms of accepting valid color formats and rejecting invalid ones. For demonstration purposes, I've adapted a creation mutation to include the primaryColor field. To keep this post focused and concise, I won't detail all the code changes here, but the following screenshots illustrate the successful implementation and error handling. Calling the mutation (createTechnology) successfully: Calling the mutation with forced fail (bad color hex): Conclusion The journey into the realm of custom GraphQL scalars reveals a world where data types are no longer confined to the basics. By creating and integrating scalars like the Color type, we unlock precision and specificity in our GraphQL schemas, which significantly enhance our applications' data handling capabilities. Custom scalars are more than just a technical addition; they testify to GraphQL's flexibility and power. They allow developers to express data meaningfully, ensuring that APIs are functional, intuitive, and robust. As we've seen, defining, integrating, and testing these scalars requires a blend of creativity and technical acumen. It encourages a deeper understanding of how data flows through your application and offers a chance to tailor that experience to your project's unique needs. So, as you embark on your GraphQL journey, consider the potential of custom scalars. Whether you're ensuring data integrity, enhancing API clarity, or simply making your schema a perfect fit for your application, the possibilities are as vast as they are exciting. Embrace the power of customization, and let your GraphQL schemas shine!...

Apr 10, 2024

5 mins

GraphQLJavaScript

Overview of the New Signal APIs in Angular

Overview of the New Signal APIs in Angular Google's Minko Gechev and Jeremy Elbourn announced many exciting things at NG Conf 2024. Among them is the addition of several new signal-based APIs. They are already in developer preview, so we can play around with them. Let's dig into it, starting with signal-based inputs and the new matching outputs API. Signal Based Inputs Discussions about signal-based inputs have been taking place in the Angular community for some time now, and they are finally here. Until now, you used the @Input() decorator to define inputs. This is what you'd have to write in your component to declare an optional and a required input: ` With the new signal-based inputs, you can write much less boilerplate code. Here is how you can define the same inputs using the new syntax: ` It's not only less boilerplate, but because the values are signals, you can also use them directly in computed signals and effects. That, effectively, means you get to avoid computing combined values in ngOnChanges or using setters for your inputs to be able to compute derived values. In addition, input signals are read-only. The New Output I intentionally avoid calling them signal-based outputs because they are not. They still work the same way as the old outputs. The Angular team has just introduced a new output API that is more consistent with the latest inputs API and allows you to write less boilerplate, similar to the new input API. Here is how you would define an output until now: ` Here is how you can define the same output using the new syntax: ` The thing I like about the new output API is that sometimes it happens to me that I forget to instantiate the EventEmitter because I do this instead: ` You won't forget to instantiate the output with the new syntax because the output function does it for you. Signal Queries I am sure most readers know the @ViewChild, @ViewChildren, @ContentChild, and @ContentChildren decorators very well and have experienced the pain of triggering the infamous ExpressionChangedAfterItHasBeenCheckedError or having the values unavailable when needed. Here is a refresher on how you would use these decorators until now: ` With the new signal queries, similar to the new input API, the values are signals, and you can use them directly in computed signals and effects. You can define the same queries using the new syntax: ` Jeremy Elbourn mentioned that the new signal queries have better type inference and are more consistent with the new input and output APIs. He also showcased a brand new feature not available with the old queries. You can now define a query as required, and the Angular compiler will throw an error if the query has no result, guaranteeing that the value won't be undefined. Here is how you can define a required query: ` Model Inputs Jeremy and Minko announced the last new feature is the model inputs. The name is vague, but the feature is cool—it simplifies the definition of two-way bindings. Until now, to achieve two-way binding, you would have to define an input and an output following a given naming convention. @Input and @Output had to be defined with the same name (followed by "Change" in the case of the output). Then, you could use the template's [()] syntax. ` ` That way, you could keep the value in sync between the parent and the child component. With the new model inputs, you can define a two-way binding with a single line of code. Here is how you can define the same two-way binding using the new syntax: ` The html template stays the same: ` The model function returns a writable signal that can be updated directly. The value will be propagated back to any two-way bindings. Conclusion The new signal-based APIs are a great addition to Angular. They allow you to write less boilerplate code and make your components more reactive. The new APIs are already in developer preview, so you can start playing around with them today. I look forward to seeing how the community will adopt these new features and what other exciting things the Angular team has in store for us, such as zoneless apps by default....

Apr 3, 2024

3 mins

AngularJavaScript

Announcing July JavaScript Marathon - Free, online training!

Join us July 22nd, 2020 for our next JavaScript Marathon! JavaScript Marathon is a full day of free, online courses on Angular, React, Vue, RxJS, and Web Performance. Come learn about some of the leading web development technologies, and concepts! Stay for one training, or stick around for the whole day! No two sessions will be the same! --- Featuring Shawn Wang @ 11:00am - 12:00pm EDT In this session we will learn how to build a fullstack serverless React + GraphQL app from scratch with authentication, storage, and multiplayer realtime collaboration, all atop infinitely scalable AWS components, with AWS Amplify! It's never been this easy to go from idea to prototype, and each piece will be livecoded in front of your very eyes! --- Featuring Michael Hladky @ 12:30pm - 1:30pm EDT The async pipe is boring! Understand the guts of Angulars change detection and why zone.js is your biggest enemy. Learn the tricks on template bindings, component rendering, and where you pay the biggest price. As a cutting edge demo, you will understand how to analyze blocking UIs over flame charts and how to avoid them. In the end, you will be able to get zone-less performance even in zone-full Angular applications! --- Featuring Nathan Walker @ 2:00pm - 3:00pm EDT During this introduction to Nativescript, you’ll get a brief overview of what Nativescript is and how it works. You’ll also learn how to create a TypeScript, Angular, Vue, and React based app, + so much more! --- Featuring Cecelia Martinez @ 3:30pm - 4:30pm EDT Looking to add testing to your skill set or just feel more confident pushing to production? In this beginner-level talk, we will walk through the process of installing, configuring, and writing a critical-path test using Cypress. Written in JavaScript and built on the popular Mocha and Chai libraries, the free and open-source Cypress Test Runner gets you up to speed with end-to-end testing fast. We will also cover general testing strategies for beginners, including how to decide what to test and how to ensure your test suite is effective. --- Featuring Jesse Tomchak @ 5:00pm - 6:00pm EDT Setting up user authorization and authentication can be a minefield of security practices, token verification, valid callback urls, salt hashes, and more. Now take all those struggles and sprinkle them over serverless functions! When all we want to do is get past the login page to our actual application. We'll walk through setting up secure oAuth with AWS Lambda functions, covering common pitfalls, so that you can get back to the fun part of your project. --- Tune in next month for another full day of JavaScript Marathon! Need private trainings for your company? If you would like to learn more about how you can leverage This Dot’s expertise to upskill your team, and reinvigorate your developers with new knowledge about the web’s leading development technologies, visit the trainings page....

Jul 8, 2020

4 mins

EnterpriseGeneralJavaScriptTraining

End-to-end type-safety with JSON Schema

End-to-end type-safety with JSON Schema I recently wrote an introduction to JSON Schema post. If you’re unfamiliar with it, check out the post, but TLDR: It’s a schema specification that can be used to define the input and output data for your JSON API. In my post, I highlight many fantastic benefits you can reap from defining schemas for your JSON API. One of the more interesting things you can achieve with your schemas is end-to-end type safety from your backend API to your client application(s). In this post, we will explore how this can be accomplished slightly deeper. Overview The basic idea of what we want to achieve is: * a JSON API server that validates input and output data using JSON Schema * The JSON Schema definitions that our API uses transformed into TypeScript types With those pieces in place, we can achieve type safety on our API server and the consuming client application. The server side is pretty straightforward if you’re using a server like Fastify with already enabled JSON Schema support. This post will focus on the concepts more than the actual implementation details though. Here’s a simple diagram illustrating the high-level concept: We can share the schema and type declaration between the client and server. In that case, we can make a request to an endpoint where we know its type and schema, and assuming the server validates the data against the schema before sending it back to the client, our client can be confident about the type of the response data. Marrying JSON Schema and TypeScript There are a couple of different ways to accomplish this: * Generating types from schema definitions using code generation tools * Creating TypeBox definitions that can infer TypeScript types and be compiled to JSON Schema I recommend considering both and figuring out which would better fit your application and workflows. Like anything else, each has its own set of trade-offs. In my experience, I’ve found TypeBox to be the most compelling if you want to go deep with this pattern. Code generation A couple of different packages are available for generating TS types from JSON Schema definitions. * https://github.com/bcherny/json-schema-to-typescript * https://github.com/vega/ts-json-schema-generator They are CLI tools that you can provide a glob path to where your schema files are located and will generate TS declaration files to a specified output path. You can set up an npm hook or a similar type of script that will generate types for your development environment. TypeBox TypeBox is a JSON Schema type builder. With this approach, instead of json files, we define schemas in code using the TypeBox API. The TypeBox definitions infer to TypeScript types directly, which eliminates the code generation step described above. Here’s a simple example from the documentation of a JSON Schema definition declared with TypeBox: ` This can then be inferred as a TypeScript type: ` Aside from schemas and types, TypeBox can do a lot more to help us on our type-safety journey. We will explore it a bit more in upcoming sections. Sharing schemas between client and server applications Sharing our JSON Schema between our server and client app is the main requirement for end-to-end type-safety. There are a couple of different ways to accomplish this, but the simplest would be to set up our codebase as a monorepo that contains both the server and client app. Some popular options for TypeScript monorepos are: PNPM, Turborepo, and NX. If a monorepo is not an option, you can publish your schema and types as a package that can be installed in both projects. However, this setup would require a lot more maintenance work. Ultimately, as long as you can import your schemas and types from the client and server app, you are in good shape. Server-to-client validation and type-safety For the sake of simplicity, let's focus on data flowing from the server to the client for now. Generally speaking, the concepts also apply in reverse, as long as your JSON API server validates your inputs and outputs. We’ll look at the most basic version of having strongly typed data on the client from a request to our server. Type-safe client requests In our server application, if we validate the /users endpoint with a shared schema - on the client side, when we make the request to the endpoint, we know that the response data is validated using the user schema. As long as we are confident of this fact, we can use the generated type from that schema as the return type on our client fetch call. Here’s some pseudocode: ` Our server endpoint would look something like this: ` You could get creative and build out a map that defines all of your endpoints, their metadata, and schemas, and use the map to define your server endpoints and create an API client. Transforming data over the wire Everything looks stellar, but we can still take our efforts a bit further. To this point, we are still limited to serialized JSON data. If we have a created_at field (number or ISO string) tied to our user, and we want it to be a Date object when we get a hold of it on the client side - additional work and consideration are required. There are some different strategies out there for deserializing JSON data. The great thing about having shared schemas between our client and server is that we can encode our type information in the schema without sending additional metadata from our server to the client. Using format to declare type data In my initial JSON Schema blog post, I touched on the format field of the specification. In our schema, if the actual type of our date is a string in ISO8601 format, we can declare our format to be "date-time". We can use this information on the client to transform the field into a proper Date object. ` Transforming serialized JSON Data This can be a little bit tricky; again, there are many ways to accomplish it. To demonstrate the concept, we’ll use TypeBox to define our schemas as discussed above. TypeBox provides a Transform type that you can use to declare, encode, and decode methods for your schema definition. ` It even provides helpers to statically generate the decoded and encoded types for your schema ` If you declare your decode and encode functions for your schemas, you can then use the TypeBox API to handle decoding the serialized values returned from your JSON API. Here’s what the concept looks like in practice fetching a user from our API: ` Nice. You could use a validation library like Zod to achieve a similar result but here we aren’t actually doing any validation on our client side. That happened on the server. We just know the types based on the schema since both ends share them. On the client, we are just transforming our serialized JSON into what we want it to be in our client application. Summary There are a lot of pieces in play to accomplish end-to-end type safety. With the help of JSON Schema and TypeBox though, it feels like light work for a semi-roll-your-own type of solution. Another great thing about it is that it’s flexible and based on pretty core concepts like a JSON API paired with a TypeScript-based client application. The number of benefits that you can reap from defining JSON Schemas for your APIs is really great. If you’re like me and wanna keep it simple by avoiding GraphQL or other similar tools, this is a great approach....

Apr 17, 2024

6 mins

JSONTypeScript

Free Angular Training during JavaScript Marathon with This Dot Labs

This Dot

You might also like

How to create and use custom GraphQL Scalars

Overview of the New Signal APIs in Angular

Announcing July JavaScript Marathon - Free, online training!

End-to-end type-safety with JSON Schema

You might also like

How to create and use custom GraphQL Scalars

Overview of the New Signal APIs in Angular

Announcing July JavaScript Marathon - Free, online training!

End-to-end type-safety with JSON Schema