JS Marathon

Announcing October JavaScript Marathon - Free, online training!

Sep 23, 2020

2 min read

JavaScript Marathon - 4 Part Series

Join us October 28th, 2020 for our next JavaScript Marathon!

JavaScript Marathon is a full day of free, online courses on React, TypeScript, GraphQL, and more. 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!

React Hooks 201

Featuring Kyle Hill @ 11:00am - 12:00pm EDT

It might have taken a little while, but: have you mastered the use of useState, and maybe even (mostly) understand what useEffect is doing at this point? Cool. Let’s level up our React Hooks skills further by diving into some of the other tools in our box. We’ll leverage useContext and useReducer to create an easy to implement interaction and data flow that scales along with your application and your team.

Getting Started with Eleventy

Featuring Kyle Mitofsky @ 12:30pm - 1:30pm EDT

Eleventy is a JavaScript based Static Site Generator (SSG) that's designed around performance, accessibility, and simplicity. Take your first steps to build out front end designs, websites, and content with this walk through that'll get you set up on your first eleventy site. Learn some of the basics with some patterns and best practices as well.

TypeScript for Beginners

Featuring Dacey Nolan @ 2:00pm - 3:00pm EDT

During this introduction to TypeScript, we will cover what TypeScript is, what benefits it provides, and how you can use it in your projects. Code with me or just follow along as we dive into each of the types and learn how to use them.

Automating GraphQL Client Code Generation

Featuring Kevin Wolf @ 3:30pm - 4:30pm EDT

In this talk, we will learn how to streamline Front End Development by generating type-safe GraphQL Operations for Apollo Client.

Building GraphQL Resolvers

Featuring Josh Oppenheim @ 5:00pm - 6:00pm EDT

Have you ever wanted to know how graphql resolvers work or why we use them? In this training we will talk about the philosophy behind resolvers and how they fit in the greater GraphQL flow. We will take a look at how the graphql-js library implements them and we will write some of our own. We will discuss some possible requests from consumers and write resolvers to accommodate the needs presented.

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.

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

A Breakdown of RxJS 7.0 Performance Improvements

It’s official. RxJS 7.0 has been deemed stable and is now available in its beta form. The core team, committed to maintaining a dependable and adaptable reactive programming tool, has built this new release to improve many aspects of developer experience without triggering changing breaks to existing code. Through a partnership with Google, the RxJS core team was able to test its latest release by integrating the library into the Google 3 monorepository. In doing so, they ran RxJs against thousands of build targets, and across countless applications, to identify where code breaks were happening, and what could be done to ensure stronger stability. Updated Typing RxJS 7.0 is written in Typescript 3.8, which allows users to leverage all of Typescript’s latest features. For example, RxJS’ typing inference capacity, especially with respect to how the library handles generics, has significantly improved. Previous versions struggled to type larger rests of arguments, with prior upper bound limits not usually exceeding 8 or 9 values. These limitations, however, have been removed, allowing developers to pass an infinite number of values with one call. The team was also able to fix many antiquated types that did not reflect the runtime behavior of actual APIs. As a result, several Observables, including *'toPromise()'*, have been deprecated in order to mitigate the challenges of legacy behavior without significantly impacting existing code. New Features animationFrames(): an Observable that returns the milliseconds elapsed since the start of the Observable, which is especially useful for coding animation, and replaces previous methods of incrementing numbers. lastValueFrom() and firstValueFrom(): Observables that return the last and first values in a promise, respectfully. They improve upon *‘toPromise()’* by returning an ‘EmptyError’ when passing promises without values, and giving users more flexibility when selecting the values they want returned. AsyncIterable support: Any areas of code that previously accepted a Promise, or an Observable, now also accept AsyncIterables. rxjs-for-await: a separate library which supports async-await for-await loops via AsyncIterables. *'retry({resetOnSuccess: true})'*: In 6.0, if you had a source that errored with, for example, a retry count valued at 5, it would only error a total of 5 times, no matter how many successful messages it had passed. With *'retry({resetOnSuccess: true})'*, the retry count value will reset every time a successful message is passed. TimeStamp: an interface with a *‘now()’* method that returns a number. Name Changes: In order to create fewer collisions between four legacy operators, and creation methods with the same name... *'zip(other$)'* is now *'zipWith(other$)'*. *'combineLatest(a$, b$)'* is now *'combineLatestWith(a$, b$)'*. *'merge(partner$)'* is now 'mergeWith(partner$)'. *'concat(ender$)'* is now *'concatWith(ender$)'*. Deprecations In 7.0, no critical elements have been removed from the library, but several features have been deprecated. These include: ResultSelectors, which have been deprecated since 5.0. The process of passing scheduler arguments through functions such as ‘of()’ or ‘range()’ has been deprecated, and should be replaced by using ‘scheduled()’ or ‘observeOn()’. This has been done in order to remove scheduling logic from operators that don’t need it. Some subscription signatures will be deprecated. With this newest release, subscriptions should only be called with a single function, or a partial or complete Observable. The same will also go for tap signatures. This will simplify the development process and help eventually make the library more lean with future releases. Functions that pull in schedulers are now deprecated as of this release in order to prepare users for the eventual phase-out of passing schedulers to certain functions. Looking Forward to 7.1 and Beyond In order to support future changes to the library, the RxJS team will begin introducing ESLint transformations. These updates will help developers remove deprecated code, such as APIs, from their applications, and prepare users for future, major releases as the library becomes faster and leaner. However, Ben Lesh, RxJS core team lead, ensures that no breaking changes will be scheduled until version 9.0 at the earliest. How You Can Contribute The RxJS core team welcomes enthusiastic RxJS experts to help contribute to refining version 7’s future updates. Those experienced with ESLint transformations, or who want to update documentation are welcome to contribute to this open-source library. And of course, the RxJS team relies on the amazing work of authors, bloggers, content creators, and those working in developer relations, to share insights into the library with the development community. If you’re just getting started with RxJS, check out this fantastic “1 Hour to Learn RxJS” tutorial by Ben Lesh from This Dot Labs' Javascript Marathon, where you can learn about Observables and operators, including how to build an Observable from scratch!...

Jul 31, 2020

4 mins

RxJS

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

Announcing October JavaScript Marathon - Free, online training!

JavaScript Marathon - 4 Part Series

This Dot

You might also like

How to create and use custom GraphQL Scalars

Overview of the New Signal APIs in Angular

A Breakdown of RxJS 7.0 Performance Improvements

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

How to create and use custom GraphQL Scalars

Overview of the New Signal APIs in Angular

A Breakdown of RxJS 7.0 Performance Improvements

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal