Skip to content
Daian Scuarissi

AUTHOR

Daian Scuarissi

Software Engineer

Select...
Select...
Sharing Signals and Stores: Context API in SolidJS cover image

Sharing Signals and Stores: Context API in SolidJS

Introduction Welcome to our latest blog post on SolidJS, where we delve into the world of the Context API. Context API is a popular and versatile feature in SolidJS, allowing developers to pass data and functions through the component tree without the need for props drilling. In this post, we will discuss how SolidJS implements the Context API, including the creation of contexts, sharing Signals and stores, and utilizing them within the components. Whether you are a seasoned developer, or just starting out, this post will provide valuable insights into the use of Context API in SolidJS and what are the advantages in the Reactivity ecosystem. So sit back, grab a cup of coffee, and let's dive in! What is SolidJS? SolidJS is a unique and powerful JavaScript framework that is quickly gaining popularity among developers. One of the key features that sets SolidJS apart from other frameworks is its reactive nature. How about reactivity? Reactivity is a programming paradigm through which the application automatically updates and re-renders when the data changes. This means that developers do not have to manually update the view when the data changes, saving a lot of time and effort. SolidJS achieves this reactivity by using a virtual DOM which is a lightweight representation of the actual DOM. This virtual DOM is then used to update the actual DOM, making the process of updating the view much faster and more efficient. Performance Another advantage of SolidJS is its performance. SolidJS is designed to be fast and efficient thanks to its use of a virtual DOM and a functional programming approach. By using functional components and immutability, SolidJS is able to optimize the process of re-rendering, resulting in a smoother and more responsive user experience. In addition to its reactivity and performance, SolidJS also has a small footprint and a simple API. The framework is lightweight and easy to learn, making it a great choice for developers of all skill levels. Signals: SolidJS Signals are a powerful feature that allow for easy communication between different parts of your application. They are similar to events or hooks in other frameworks, but with a few key differences. One of the key advantages of Signals in SolidJS is that they are fully reactive, meaning that they automatically update and re-render when the data changes. This makes it easy to create responsive and dynamic applications without having to manually update the view. To use Signals in SolidJS, you need to first create a signal by using the createSignal function. ` Store In SolidJS, a store works similar to other frontend frameworks. To keep things light, SolidJS creates underlying Signals only for properties that are accessed under tracking scopes. All Signals in Stores are created lazily as requested. The createStore call takes the initial value, and returns a read/write tuple similar to Signals. The first element is the store proxy which is readonly, and the second is a setter function. What About context? SolidJS provides a context API to pass data around without relying on passing props; this is useful in sharing Signals and Stores as described above. According to SolidJS docs: “Using Context has the benefit of being created as part of the reactive system and managed by it.” Getting Started: First, let’s create our context: ` Then we can consume our recently Context created: ` To use context, we'll first wrap our App component in order to provide it globally: ` We can now consume the context and our components will look like this: ` ` Conclusion In this article, we were able to use the contextAPI to share the props we want across the app, and benefit from the performance of Reactivity because of that. This will make our application more readable, but also brings some additional benefits to the app which are as follows: - avoid passing props down through multiple levels of the component tree. - reducing the number of re-renders that occur when props are passed down. - by isolating state and props to a specific context, you can make your code more organized and easier to understand. - components that use the Context API are more easily tested. Would you like to learn more about Signals and Stores, or SolidJS in general? You can see in detail how this was maximized in one of This Dot Labs' open source project starter.dev GitHub Showcases....

How to Choose Between Data Fetching Options in Next.js cover image

How to Choose Between Data Fetching Options in Next.js

How to choose between Data Fetching options in Next.js....

Understanding Next.js Data Fetching for Beginners cover image

Understanding Next.js Data Fetching for Beginners

Let's find what CSR, SSR, SSG, ISR means and how we can use it....

What's New in React 18? cover image

What's New in React 18?

Discover the new features released in React 18....

State of Angular | March 2022 Recap cover image

State of Angular | March 2022 Recap

State of Angular | March 2022 This event was co-hosted by This Dot Labs team members Rob Ocel, Software Architect and Engineering Lead, and Chris Trzesniewski, Senior Software Engineer. If you would like to watch the full event, you can find the recording here: State of Angular | March 2022 What's new in the ecosystem? What will be included in the upcoming releases? What should we expect in Angular's future? These topics were discused by a featured panel: - Mark Thompson, Developer Advocate, Google - Alex Rickabaugh, Software Engineer, Google - Madleina Scheidegger, Engineering Manager for Angular, Google. Here are some of the key takeaways: What's new in Angular? Since the launch of v13, the Angular Team has continued to improve and refine its features: - Extended Diagnostics. - Gave us better guidance and some more options to make sure that we can avoid some of the most common anti-patterns in Angular. - Enhanced component a11y. 🔥 - Since the v13 launch, the Team has made a number of improvements regarding accesibility. For example, they did an audit of the components to make sure those components passed all standard accesibility checks. You can review them here: Accesibility Angular Improvements - Typed forms. One of the most important changes introduced was the ability to check the form type and throw an error if the type is not properly set. - Standalone components. They are still working on the implementation to make standalone components happen. Other features in progress: - CDK promoting to stable - Embebbed view injector Then, we had some time for a Q&A. The highlighted questions included: Angular Components are often hard for newcomers to understand. Standalone Components should help mitigate this. How will this new Component type ease the learning curve? The team agreed that 'ng modules' are hard concepts for newcomers to learn, and they had many conversations about this opinion. 'ng modules' have more than one responsibility, and often these responsabilities have different scopes. They're tough to understand because they are doing different things in different places. Standalone components enable developers to write Angular apps without writing any 'ng modules'. Devs will still be able to use 'ng modules', and they will have the ability to perform imports. However, they won't have to learn how 'ng modules' affect the app, and that will help simplify the learning process. SCAM Pattern, and how it is related to Standalone Components. According to the team, using the SCAM pattern is the cleanest approach one can use, and Standalone components will be the SCAM pattern's next level. The team has successfully decreased the volume of tickets, issues on the backlog, and open PR's. How was the process for the team? What lessons has the team learned? According to the team, this process has been tedious, but also rewarding. This year, the team wanted to make it easier for the community to provide feedback. For example, they created a process allowing community members to suggest a feature request, and let the community vote. If the request achieves a certain number of votes, it goes to a queue for the team to review and work on. This helps the team prioritize the most essential tickets and proposals. Now, communities are looking for solutions to reduce the use of Javascript or Server Side rendering tools like Next.js or Remix. How is the Angular Team responding to these trends? The team is constantly monitoring these trends, evaluating them, and learning from them. While they want to advance the framework, they don't want do that at the expense of the experience of those who adopted a previous version of Angular. Therefore, if the team choses to include any transformative changes, they want to do it in a way that shepards all users to the updated versions. Conclusion Angular's outlook is overwhelmingly positive, and the community is growing. It is an exciting time to be an Angular developer, and there are some really exciting features coming down the pipe, so we are really excited to see what will come next....

Next.js and React.js: 5 Differences to Help You Make Your Choice cover image

Next.js and React.js: 5 Differences to Help You Make Your Choice

Next.js and React.js: 5 Differences to make your choice...

Avoid common pitfalls when using OnPush change detection in Angular cover image

Avoid common pitfalls when using OnPush change detection in Angular

By default, Angular provides two different change detection strategies: Default and OnPush. Each has his own advantages, but sometimes we run into pitfalls if we don't understand how to apply OnPush and how it works. First, we need to understand how Angular implements change detection. How Angular implements change detection? Like any other framework, Angular must have a way to synchronize its internal model state to the view. In particular, the framework by Google checks all components for changes in different occasions. These can include: - Network Requests - Mouse clicks - Mouse scrolls - Keyboard events, and more... In general, all componentes are checked. The Angular team spent a lot of effort on highly optimizing the change check internally. By default, it walks the application component's tree, an array, from start to finish. On its way, it searches for children and values that have to be compared and checked (e.g., *@Inputs()*, *@Outputs()*, and other template-bound references). But this comes with a downside. Angular cannot know which of the values is bound at some point, but us as developers, we can know when values change, and what value in an object changes, and this is where OnPush change detection comes in. OnPush change detection ` When the OnPush change detection is declared as we see above, the change detection doesn't run automatically anymore. Instead, it listens for specific changes, and only runs the change detection in those scenarios. It runs if an *@Input* changes, or if a component was marked for a check. Remember, when comparing @Inputs, they are compared by identities (*Object.is()*). OnPush and Object mutability For ex. we declare a parent component and a child component. ` If we click on changeDirector() button, we will change the name of the movie director, as we set previously the changeDetection, this will not update the director on the template. This occurs due to the fact: - we mutated the object directly - onPush works by comparing references of the inputs of the component - because we mutated an existing one, onPush change detector will not be triggered BUT, *we can avoid this situation, creating a new instance of the director instead of mutate the existing one.* ` We simply need to either avoid mutating objects directly or use an immutability library to freeze the view model data that we pass to our components. Let's see in action on Stackblitz. OnPush and event handlers If for example, we have an @Output event inside the director component, we will see that the director will show the new name and lastName information, but why is this? This occurs because the triggering of event handlers cause the onPush change detector to trigger, independent of whether the inputs have changed or not. We can then assume that OnPush is more than just checking input. Conclusion OnPush is defined this way. It runs only in certain scenarios, and we need to keep that scenarios in mind if we want our app works smoothly. Those scenarios include: - When a DOM event the component listens was received - When the | async pipe receives a new event - When a @Input() was updated by change detection - When explicitely registering the component to be checked using ChangeDetectorRef...

Creating Custom Sync Validators in Angular Reactive Forms cover image

Creating Custom Sync Validators in Angular Reactive Forms

Incorporate Angular built-in validators and create a custom SyncValidator, demonstrated through a practical example of validating a phone number in a reactive form....

Using Custom Async Validators in Angular Reactive Forms cover image

Using Custom Async Validators in Angular Reactive Forms

What is an AsyncValidator, and how we can use them to improve our forms....

State of Angular Ecosystem | December 2021 cover image

State of Angular Ecosystem | December 2021

This is a recap from the event State of Angular Ecosystem, you can see the full watch on State of Angular Ecosystem | Dic 2021. This event was hosted by Rob Ocel, Software Architect and Engineering Lead at This Dot. What's is new on the Angular Ecosystem? What should be expect on the upcoming releases? How Angular ecosystem looks like in the future? Also, we had this amazing panel: - Minko Gechev, Software engineer at Google, Angular Core team. - Ben Lesh, RxJS core team lead. - Mark Whitfeld, Software engineer at Stackblitz, NGXS corea team lead. - Brandon Roberts, Senior Angular Engineer, Nrwl & NgRx maintainer. - James Daniels, Developer Relations, Firebase. - Jessica Janiuk, Senior Software Engineer, Google. RxJS updates (Ben Lesh) Weeks ago was introduced RxJS 7.4, the latest version from the RxJS team, which has many features, but first of all, the bundle size compared between RxJS 6 vs RxJS 7 (if you include everything RxJS exports, included new features!) was cut by almost the half, so if you are thinking to switch between those versions, you should go ahead. Now, v7 has tons of typings fixes/updates, but now requires TypeScript 4.2+. Most of the new features included in the new version are: - Top-level exports - Multi-cast simplified - Improved retry ergonomics - Animation Frames - New tap features - AsyncIterable support That's was most of the most importants features delivered on RxJS 7.4, but there is more such as: - Ajax/fetch improvements - Supporting for aborting promises & more... Regarding in how many downloads has RxJS, the downloads has increased consideraly since RxJS 6 in 2018. Now we can 30M downloads a week, back then in 2018 they have only 10M per week. Stackblitz (Mark Whitfeld) Now Stackbliz has support for Angular v13, this was thanks to the upgrade of Stackblitz v2, which runs over web-containers. This new upgrade to Stackblitz v2, avoid to have custom-code depending on which framework you are running, making Stackblitz more agnostic from the framework (Angular, React, Vue) you are using. In fact, there is no custom-code to support any of the most used frameworks. NGXS (Mark Whitfeld) Now NGXS has support for Angular v13, with this mayor release there are up-to-date with the latest version of Angular. They are working on deliver another big features too. Angular Core (Minko Gechev, Jessica Janiuk) Ivy Ivy now its the default engine to run compilation in Angular, which lead us a huge increase of performance vs versions who runs other engines to compile Angular. With the implementation of Ivy as default, we can see a: - 90% reduction of computational resources. - -50 mins faster build for the biggest app in Google. - Improved debuggability and profiling. - More effective relation between Github issues vs Fixes, thanks to a huge effort from the Team. - New system for RFC process. What's new in Angular v13? With the recent release of Angular v13 some new features are delivered, which include: - Removal of IE11 support (no more polyfills file, yaaaay) - Modern angular package format. - Partially compiled Angular - Removed UMD bundles - ES2020 output - Adobe font inlining - Webpack 5 cache - Dinamic validator control - Better a11y What are we building next? Some of the upcoming improvements are: - Extended analysis - Simplified factory API - Advanced guides - MDC Web Standalone components Maybe some of the biggest updates which are upcoming on the next versions of Angular are Standalone components, who will run without adding to any module. This Standalone component will be bootstrapped directly into the Angular module, and the bundle will be reduced significantly. NgRx (Brandon Roberts) The most recent version of NgRx added some new features as: - Angular v13 support - RxJS 7 support - Ivy compiled libraries support - Feature creators - Improved selectors - Contributors page Nx (Brandon Roberts) The recent release of Nx, which is v13.2, also now include Angular v13 support. Also NgRx v13, and NestJS 8 support was included in the most recen version. Now, there is a RxJS 7 upgrade option for Nx. AngularFire (James Daniels) The official library from Firebase to Angular also release some of the next features: - Firebase v9 support, entirely tree-shakable support, RxJS 7 & Angular v13 support. - Firebase v8 compatibility. - Internally uses AngularFire, increased agility and less duplication. - Partial compilation, Ivy support. - Powerful new schematics In the upcoming releases for AngularFire, the team is working to improve the next items: - Documentation drive - ng deploy capabilities - More schematics on the way... - Better bundling/rehydration - Prebuilt UI components Conclusion Angular v13 bring to us so many new features, therefore the Ecosystem of Angular is updating to support this new release. Some of the most libraries used with Angular are pushing forward and taking the framework from Google to the next level. Also the Angular team, is listening to the community and making the upcoming releases more beginner-friendly such as `Standalone components. As Angular dev, we celebrate the removal of IE11 support without that, we can take advantages of most CSS features who are not supported in that browser....

Clean Up Your Code With Design Patterns in Javascript  cover image

Clean Up Your Code With Design Patterns in Javascript

JavaScript Marathon | Design patterns are a bit of a controversial topic in the dev community. While some developers believe they are overly complicated, others are dogmatic about using them....

Improving Angular ngFor using trackById Directive cover image

Improving Angular ngFor using trackById Directive

Here's how you can improve your Angular app using trackBy in your *ngFor directive....