Javascript

This.JavaScript: State of Frameworks- Polymer/Web Components Update

Oct 28, 2019

6 min read

Hosted by This.JavaScript, an online event where developers learn about the latest news in JavaScript, State of Frameworks and Libraries covered all the breaking news in the world of frameworks.

On Feb. 19, State of Frameworks speakers, including many of the best and brightest from the development world, gave us updates on all things frameworks.

Here’s some of what Justin Fagnani, who works at Google on Web Components and Polymer, had to say about what’s coming up for Polymer and Web Components.

Justin Fagnani — Polymer.js at Google — @justinfagnani

Releases

Since the last update, there have been a lot of releases in the Polymer project and elsewhere in the community.

Salesforce recently released their Lightning Web Components, for example. Salesforce moved their entire client-side SDK away from a custom framework type of solution to pure Web Components.

Web Components has already seen a great deal of adoption and enterprise, and Salesforce is a big move towards even more. Salesforce brings with it around 4 million developers on their platform, so this is a big deal for Web Components’ future.

Similarly, Ionic just released Ionic v4, which is a rewrite of all their libraries and components to be more framework-agnostic. Ionic is using their own stencil Web Components compiler to create all the Ionic components in there.

Also recently released are the first stable versions of LitElement and lit-html, which are the next generation libraries from the Polymer group.

LitElement and lit-html

lit-html

For those who are unfamiliar, lit-html is a new html templating engine. It write templates in JS using template literals. It also renders and updates them very efficiently, only updating the parts that change. Lit-html also doesn’t use a v-DOM or do any diffing, which both typically require overhead for the extra memory allocation.

Lit-html has several major benefits. It’s very small — only about 3.1K if modules are bundled, minified, and compressed. It’s also very fast, clocking in at around the time that Inferno runs, or sometimes even faster.

Lit-html is written nearly as pure ES2017. It’s distributed in modules, so it can be used in modern browsers with no extra steps at all. The feedback so far has been very positive, even from people working in other frameworks like Angular and React.

You can see in the syntax its dynamic and static portions. Not using a vDOM or walking the tree — instead “remembering” where the dynamic portion was and updating it as needed — saves a lot of work and adds to the ergonomy of the engine.

Lit-html recently gained some new syntax to control how bindings are implemented. You can bind to text, an attribute, or properties. You can also bind to any event using an event listener, such as bubbling or capturing an event.

The Stacklits team has been working on a template for lit-html. This template takes advantage of the fact that there’s little build required. Full page reloads are available on every keystroke; because there’s no build, it’s basically instant. This means that hot module loading is essentially available without its usual pitfalls.

LitElement 2.0

LitElement, also recently released, is a lightweight base class for Web Components, only about 2 KB on top of lit-html. LitElement uses lit-html for rendering.

It also has reactive, declarative properties and feeds them through an asynchronous rendering pipeline.

LitElement uses shadowDOM for styling and looks a lot like React but without JSX, usually using standard syntax.

Pre-release Adoption

Web Components have had several encouraging adoption announcements recently. In particular, the community is noticing early adoption from enterprises with existing design systems. Enterprises like SAP, ING, British Gas, Williams Sonoma, and others have already started using Web Components.

Chrome 73

Chrome 73 is going to ship with two great features for Web Components.

The first is Constructible StyleSheets, a feature that allows you to create a stylesheet once and parse it only once. You simply have to give it some CSS text. After that, for every component that wants to use a StyleSheet, you can add it to the shadowDOM for that component. This is just a JS reference to a single shared StyleSheet.

This feature gives a nice boost in performance of up to 30% in some benchmarks, making Web Components faster. If you mutate the stylesheet, changes can affect all of those components at once, even though they’re in encapsulated shadowRoots.

LitElements automatically uses this feature when available. Pages that use LitElement will be faster on Chrome 73.

The CSS tag will detect whether you have Constructible StyleSheets, and if you do, it will create a stylesheet out of that CSS text. If not, it will inject a plain style tag into the ShadowRoot.

Another new feature of Chrome 73 that will have great implications for Web Components is CSS ShadowParts, or ::part().

ShadowDOM gives you style encapsulation. Sometimes you want to be able to explicitly expose something out of that ShadowRoot for styling purposes.

You add this new ::part() attribute to elements inside a ShadowRoot. Outside of the ShadowRoot, just like in Pseudo-Elements, you’re able to select a part and make styling changes. This is a really important feature for theming in an encapsulated style world.

These features will help Web Components march down this progression of enabling developers to do what only the platform could do. The story of Web Component is about gradually exposing Native features to developers. In the future, custom Pseudo-Classes will complete that story with Custom State.

Usage Stats

Looking at the stats, it’s clear that Web Components have become more popular. Almost 10 percent of page views in Chrome use Web Components. This is one of the most successful platform features launched in recent years, even more successful than Web Workers, Web Audio, and Service Workers. Nearly every web user uses Web Components every day that they browse the web.

What’s Next?

Lit-html doesn’t support SSR yet, so that’s in the works for the future. Lit-html will also eventually have streaming SSR, so that every static and dynamic chunk of lit-html can be streamed independently as it is resolved.

Developers are also working on incremental rehydration for lit-html. Build-time optimizations will decrease bootup time even further.

For Lit-Element, developers are adding ::part() support with a fall-back. Other goals include reducing bootup costs and adding SSR. There are also a number of Async Helpers in the queue for Lit-Element.

For the Native platform, template instantiation is moving forward. ::theme(), similar to ::part(), will also be implemented soon for more styling control. HTML Modules and CSS Modules are also likely in the works for the future.

On deck is also work with polyfills, making them easier to use and transparently implement the specs more accurately. This is one of the major roadblocks to Web Components adoption, so that will be a high priority going forward.

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.

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

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

6 Steps to AI Adoption: Building with AI APIs

Tracy Lee, Jerome Hardaway, and Rob Ocel continue their six part series on the six steps for AI adoption. In this episode they discuss AI API integration and better building with AI models. One key takeaway was the importance of choosing the right tools for specific tasks. Jerome emphasized the significance of using content moderation APIs for filtering inappropriate content as an example. These tools help developers improve user experiences by ensuring content accuracy and appropriateness. However, Jerome also warned against blindly relying on AI tools and encouraged programmers to assess their benefits and limitations before implementation. The discussion also touched on how AI impacts coding abilities and problem-solving. AI-powered tools can boost developer productivity by automating repetitive tasks and offering helpful suggestions. Yet, it's important to strike a balance and not become overly dependent on AI, which could hinder critical thinking and problem-solving skills crucial for programmers. One challenge discussed was the difficulty of working with poorly documented APIs, which makes it hard for developers to understand and utilize AI tools effectively. While AI has the potential to enhance productivity and user experiences, it's important for developers to choose the right tools and avoid over-reliance. By carefully evaluating AI tools and investing in clear documentation, developers can leverage AI effectively to improve their coding abilities and problem-solving skills. Download this episode here!...

Apr 15, 2024

2 mins

AIArtificial Intelligence

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

This.JavaScript: State of Frameworks- Polymer/Web Components Update

Justin Fagnani — Polymer.js at Google — @justinfagnani

Releases

LitElement and lit-html

lit-html

LitElement 2.0

Pre-release Adoption

Chrome 73

Usage Stats

What’s Next?

You might also like

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Overview of the New Signal APIs in Angular

6 Steps to AI Adoption: Building with AI APIs

How to create and use custom GraphQL Scalars

You might also like

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Overview of the New Signal APIs in Angular

6 Steps to AI Adoption: Building with AI APIs

How to create and use custom GraphQL Scalars