Những Concepts Cốt Lõi Để Trở Thành Bậc Thầy Của Mọi FrontEnd Frameworks

TypeScript And “Any” Type

TypeScript is a strongly typed programming language that builds on JavaScript, giving you a better ability to detect errors and describe your code. But sometimes you don't know the exact type of value that you're using because it comes from user input or a third-party API. In this case, you want to skip the type checking and allow the value to pass through the compile check. The TypeScript any type is the perfect solution for you because if you use it, the TypeScript compiler will not complain about the type issue. This blog will help you understand the any type in TypeScript, but before doing that, let's begin with some basic concepts! What is TypeScript? TypeScript checks a program for errors before execution and does so based on the kinds of values; it’s a static type checker. Superset of JavaScript TypeScript is a language that is a superset of JavaScript: JS syntax is, therefore, legal TS. However, TypeScript is a typed superset that adds rules about how different kinds of values can be used. Runtime Behavior TypeScript is also a programming language that preserves JavaScript's runtime behavior. This means that if you move code from JavaScript to TypeScript, it is guaranteed to run the same way, even if TypeScript thinks the code has type errors. Erased Types Roughly speaking, once TypeScript’s compiler is done with checking your code, it erases the types to produce the resulting compiled code. This means that once your code is compiled, the resulting plain JS code has no type information. An easy way of understanding TypeScript A languageA superset of JavaScriptPreserver the runtime behavior of JavaScriptType checker layer JavaScript + Types = TypeScript Basic typing Type annotations TypeScript uses type annotations to explicitly specify types for identifiers such as variables, functions, objects, etc. // Syntax : type Once an identifier is annotated with a type, it can be used as that type only. If the identifier is used as a different type, the TypeScript compiler will issue an error. let counter: number; counter = 1; counter = 'Hello'; // Error: Type '"Hello"' is not assignable to type 'number'. The following shows other examples of type annotations: let name: string = 'John'; let age: number = 25; let active: boolean = true; // Array let names: string[] = ['John', 'Jane', 'Peter', 'David', 'Mary']; // Object let person: { name: string; age: number }; person = { name: 'John', age: 25 }; // Valid // Function let sayHello : (name: string) => string; sayHello = (name: string) => { return `Hello ${name}`; }; Type inference Type inference describes where and how TypeScript infers types when you don’t explicitly annotate them. For example: // Annotations let counter: number; // Inference: TypeScript will infer the type the `counter` to be `number` let counter = 1; Likewise, when you assign a function parameter a value, TypeScript infers the type of the parameter to the type of the default value. For example: // TypeScript infers type of the `max` parameter to be `number` const setCounter = (max = 100) => { // ... } Similarly, TypeScript infers the return type to the type of the return value: const increment = (counter: number) => { return counter++; } // It is the same as: const increment = (counter: number) : number => { return counter++; } The following shows other examples of type inference: const items = [0, 1, null, 'Hi']; // (number | string)[] const mixArr = [new Date(), new RegExp('\d+')]; // (RegExp | Date)[] const increase = (counter: number, max = 100) => { return counter++; }; // (counter: number, max?: number) => number Contextual typing TypeScript uses the locations of variables to infer their types. This mechanism is known as contextual typing. For example: document.addEventListener('click', (event) => { console.log(event.button); // Valid }); In this example, TypeScript knows that the event the parameter is an instance of MouseEvent because of the click event. However, when you change the click event to the scroll the event, TypeScript will issue an error: document.addEventListener('scroll', (event) => { console.log(event.button); // Compile error }); // Property 'button' does not exist on type 'Event'. TypeScript knows that the event in this case, is an instance of UIEvent, not a MouseEvent. And UIEvent does not have the button property, therefore, TypeScript throws an error. Other examples of contextual typing // Array members const names = ['John', 'Jane', 'Peter', 'David', 'Mary']; // string[] names.map(name => name.toUpperCase()); // (name: string) => string // Type assertions const myCanvas = document.getElementById('main-canvas') as HTMLCanvasElement; Type inference vs Type annotations Type inferenceType annotationsTypeScript guesses the typeYou explicitly tell TypeScript the type What exactly is TypeScript any? When you don’t explicitly annotate and TypeScript can't infer exactly the type, that means you declare a variable without specifying a type, TypeScript assumes that you use the any type. This practice is called implicit typing. For example: let result; // Variable 'result' implicitly has an 'any' type. So, what exactly is any? TypeScript any is a particular type that you can use whenever you don't want a particular value to cause type-checking errors. That means the TypeScript compiler doesn't complain or issue any errors. When a value is of type any, you can access any properties of it, call it like a function, assign it to (or from) a value of any type, or pretty much anything else that’s syntactically legal: let obj: any = { x: 0 }; // None of the following lines of code will throw compiler errors. // Using `any` disables all further type checking, and it is assumed // you know the environment better than TypeScript. obj.foo(); obj(); obj.bar = 100; obj = 'hello'; const n: number = obj; Looking back at an easier-to-understand any: A special type.Skip/Disable type-checking.TypeScript doesn't complain or issue any errors.Default implicit typing is any. Note that to disable implicit typing to the any type, you change the noImplicitAny option in the tsconfig.json file to true. Why does TypeScript provide any type? As described above, while TypeScript is a type checker, any type tells TypeScript to skip/disable type-checking. Whether TypeScript has made a mistake here and why it provides any type? In fact, sometimes the developer can't determine the type of value or can't determine the return value from the 3rd party. In most cases they use any type or implicit typing as any. So they seem to think that TypeScript provides any to do those things. So, is that the root reason that TypeScript provides any? Actually, I think there is a more compelling reason for TypeScript providing any that the any type provides you with a way to work with the existing JavaScript codebase. It allows you to gradually opt-in and opt out of type checking during compilation. Therefore, you can use the any type for migrating a JavaScript project over to TypeScript. Conclusion TypeScript is a Type checker layer. The TypeScript any type allows you to store a value of any type. It instructs the compiler to skip type-checking. Use the any type to store a value when you migrate a JavaScript project over to a TypeScript project. In the next blog, I will show you more about the harmful effects of any and how to avoid them. Hope you like it! See you in the next blog! Reference TypeScript handbookTypeScript tutorial Author: Anh Nguyen

A Better Way To Use Services In React Application

Sometimes you have/want to create and use a service in your application for the DRY principle. But do you know exactly what is a service? And what is the best way to use services in React applications? Hi everyone! It's nice to meet you again in React related series. In the previous article, we discussed about effective state management in React, we learned about Context: what is it? when to use it? One of the use cases is using a context to share a collection of services through the components tree, but what kind of things can be called a service? And how is it integrated into React application? Let's discover the following sections: What is a Service? Service is just a group of helper functions that handle something particularly and can be reused across application, for example: Authentication Service that includes authentication status checking, signing in, signing out, getting user info …Http Service that handles request header, request method, request body … How to use? There are different kinds of implementation and usage, I just provide my favorite one that follows Angular module/services provider concepts. Create a service A service is a JavaScript regular class, nothing related to React. export default class ApiService { constructor() {} _setInterceptors() {} _handleResponse_() {} _handleError_() {} get() {} post() {} put() {} delete() {} } export default class AuthService { constructor() {} isAuthenticated() {} getUserInfo() {} signIn() {} signOut() {} } Create a Context Create a context with provider and pass services as props. import { createContext, useState } from 'react'; import { ApiService, AuthService } from '@services'; const services = { apiService: new ApiService(), authService: new AuthService() }; const AppContext = createContext(); const { Provider } = AppContext; const AppProvider = ({ children }) => { return <Provider value={{ services }}>{children}</Provider>; }; export { AppContext, AppProvider } Use a context Place a context provider at an appropriate scope, all consumers should be wrapped in it. import { AppProvider } from './context/AppContext'; import ComponentA from './components/ComponentA' const App = () => { return ( <AppProvider> <div className="app"> <ComponentA /> </div> </AppProvider> ); }; export default App; Inside a child component, use React hooks useContext to access services as a context value. import { useContext, useEffect } from 'react'; import { AppContext } from '../context/AppContext'; const ChildComponent = () => { const { services: { apiService, authService } } = useContext(AppContext); useEffect(() => { if (authService.isAuthenticated()) { apiService.get(); } }, []); return <></>; } export default ComponentA; Above are simple steps to integrate services with context. But it would be complicated in the actual work. Consider organizing context with approriate level/scope. My recommendation is to have two kinds of service contexts in your application: App Services Context to put all singleton services. Bootstrap it once at root, so only one instance for each is created while having them shared over the component tree.For others, create separate contexts and use them anywhere you want and whenever you need. Alternatives Service is not the only one way to deal with reusable code, it depends on what you intend to do, highly recommend to: Use a custom hook, if you want to do reusable logic and hook into a state.Use a Higher-order component, if you want to do the same logic and then render UI differently. Reference Does React Context replace React Redux?React RetiX - another approach to state management Author: Vi Nguyen

Does React Context Replace React Redux?

Table of contents What is Context?How and when to use a Context?When to use Redux?Does Context replace Redux? context-or-redux-1024x768 As you all know, nowadays, React has become one of the most famous JavaScript libraries in the world. It's easy to learn and use. It comes with a good supply of documentation, tutorials, and training resources. Any developer who comes from a JavaScript background can easily understand and start creating web apps using React in a few days with the main concepts: JSXRendering ElementsComponents and PropsState and LifecycleHandling Events But to become an expert in React, it would take more time. You have to deep dive into advanced things: Higher-Order componentsContextCode-SplittingAvoiding unexpected rerenderEspecially, Effective state management When it comes to state management in React applications, we instantly think about React Redux. This is a favorite and widespread tool across developer's communities and applications. Recently, a lot of questions have come to us about using React Context as an alternative for React Redux. To answer those questions, have a brief of React Context first. What is the context? The context was originally introduced for passing props through the component tree, but since newer versions, React provided the powerful feature that allows updating context from a nested component. Meanwhile, Context can now be a state management tool. Let's see how easy it works? Context with Hooks There are many ways to integrate Context, in this article, I just demo the simplest one Create a context import { createContext } from 'react'; export const ThemeContext = createContext(defaultTheme); So simple, createContext is the built-in function that allows you to create a context with default value. Create a provider A provider allow consuming components to subscribe to context changes const { Provider } = ThemeContext; const ThemeProvider = ( { children } ) => { const theme = { ... }; return <Provider value={{ theme }}>{children}</Provider>; }; Create a consumer The simplest way to subscribe to the context value is to use the useContext hook. export const ThemeInfo = () => { const { theme } = useContext(ThemeContext); return ( <div>backgroundColor: {theme?.background}</div> ); } A consumer must be wrapped inside a Provider if not it would not be noticed and then re-render when context data changes. <App> <ThemeProvider> <ThemeInfo></ThemeInfo> </ThemeProvider> </App> Update the context from a consumer It is sometimes necessary to update the context from consumers, context itself doesn't provide any method to do that, but together with hooks, it can be easy: Use useState to manage context valuesetTime is passed as a callback const { Provider } = ThemeContext; const ThemeProvider = ( { children } ) => { const [theme, setTheme] = useState(defaultTheme); return <Provider value={{ theme, setTheme }}>{children}</Provider>; }; From a consuming component, we can update the context value by executing the callback provided by context export const ButtonChangeTheme = () => { const { setTheme } = useContext(ThemeContext); return ( <button onClick={() => setTheme(newTheme)}>Change</button> ); } Again, don't forget to wrap ButtonChangeTheme consumer inside ThemeProvider <App> <ThemeProvider> <ButtonChangeTheme></ButtonChangeTheme> </ThemeProvider> </App> When to use context? As official guideline Context is designed to share data that can be considered global for a tree of React components. Below are common examples of data that Context can cover: Application configurationsUser settingsAuthenticated userA collection of services How to use context in a better way? As mentioned before, when the context value changes, all consumers that use the context will be immediately re-rendered. So putting it all into one context is not a good decision. Instead, create multi-contexts for different kinds of data. EX: one context for Application configurations, one for Authenticated user and others.Besides separating unrelated contexts, using each in its proper place in the component tree is equally significant.Integrate context adds complexity to our app by creating, providing, and consuming the context, so drilling props through 2-3 levels in a tree component is not a problem(Recommended to use instead of context)Restrictively apply context for high-frequency data updated, because context is not designed for that.​ What about React Redux? Unlike Context, React Redux is mainly designed for state management purposes, and covers it well. However, take a look at some highlights from Redux team: Not all apps need Redux. It's important to understand the kind of application you're building, the kinds of problems that you need to solve, and what tools can best solve the problems you're facing. You'll know when you need Flux. If you aren't sure if you need it, you don't need it. Don't use Redux until you have problems with vanilla React. Those recommendations clearly answer the question: When to use Redux? Conclusion So, Does React Context replace React Redux? The short answer is no, it doesn’t. React Redux and React Context can be used together instead of as alternatives. But how to use them together? It depends. If you understand the main concepts for each: React Context is designed for props drilling, it also has ways to update context data, but is recommended to deal with the simple follow of data changes.Redux is built for state management, especially for the frequently updated states used at many places in the application. Based on that you can easily decide what should be implemented in your application. In the end, try to use Context first, if something is not covered by Context, it's time to use Redux. Enjoy coding! Reference Context official docsRedux FAQ: generalIf you are not interested in using Redux, you can check out React RetiX for a different approach to state management.I can not remember all the sources I have read, but it helps a lot in having comparison between Context and Redux. Thank you and sorry for not listing them all in this article!​ Author: Vi Nguyen

Ionic vs. React Native: A Comprehensive Comparison

Ionic vs. React Native is a common debate when choosing a framework for cross-platform app development. Both frameworks allow developers to create apps for multiple platforms from a single codebase. However, they take different approaches and excel in different scenarios. Here’s a detailed comparison. Check out for more comparisons like this with React Native React Native vs. Kotlin Platform Native Script vs. React Native The origin of Ionic Framework Ionic Framework was first released in 2013 by Max Lynch, Ben Sperry, and Adam Bradley, founders of the software company Drifty Co., based in Madison, Wisconsin, USA. What's the idea behind Ionic? The creators of Ionic saw a need for a tool that could simplify the development of hybrid mobile apps. At the time, building apps for multiple platforms like iOS and Android required separate codebases, which was time-consuming and resource-intensive. Therefore, the goal was to create a framework that allowed developers to use web technologies—HTML, CSS, and JavaScript—to build apps that could run on multiple platforms with a single codebase. Its release and evolution over time The first version of Ionic was released in 2013 and was built on top of AngularJS. It leveraged Apache Cordova (formerly PhoneGap) to package web apps into native containers, allowing access to device features like cameras and GPS. 2016: With the rise of Angular 2, the team rebuilt Ionic to work with modern Angular. The renovation improved performance and functionality. 2018: Ionic introduced Ionic 4, which decoupled the framework from Angular, making it compatible with other frameworks like React, Vue, or even plain JavaScript. 2020: The company developed Capacitor, a modern alternative to Cordova. It provides better native integrations and supports Progressive Web Apps (PWAs) seamlessly. Key innovations of Ionic First of all, Ionic popularized the use of web components for building mobile apps. In addition, it focused on design consistency, offering pre-built UI components that mimic native app designs on iOS and Android. Thirdly, its integration with modern frameworks (React, Vue) made it appealing to a broader developer audience. Today, Ionic remains a significant player in the hybrid app development space. It's an optimal choice for projects prioritizing simplicity, web compatibility, and fast development cycles. It has a robust ecosystem with tools like Ionic Studio. Ionic Studio is a development environment for building Ionic apps. The origin of React Native React Native originated at Facebook in 2013 as an internal project to solve challenges in mobile app development. Its public release followed in March 2015 at Facebook’s developer conference, F8. Starting from the problem of scaling mobile development In the early 2010s, Facebook faced a significant challenge in scaling its mobile app development. They were maintaining separate native apps for iOS and Android. It made up duplicate effort and slowed down development cycles. Additionally, their initial solution—a hybrid app built with HTML5—failed to deliver the performance and user experience of native apps. This failure prompted Facebook to seek a new approach. The introduction of React for Mobile React Native was inspired by the success of React, Facebook’s JavaScript library for building user interfaces, introduced in 2013. React allowed developers to create fast, interactive UIs for the web using a declarative programming model. The key innovation was enabling JavaScript to control native UI components instead of relying on WebView rendering. Its adoption and growth React Native quickly gained popularity due to its: Single codebase for iOS and Android.Performance comparable to native apps.Familiarity for web developers already using React.Active community and support from Facebook. Prominent companies like Instagram, Airbnb, and Walmart adopted React Native early on for their apps. Today, React Native remains a leading framework for cross-platform app development. While it has faced competition from newer frameworks like Flutter, it continues to evolve with strong community support and regular updates from Meta (formerly Facebook). Ionic vs. React Native: What's the key differences? Core Technology and Approach React Native Uses JavaScript and React to build mobile apps.Renders components using native APIs, resulting in apps that feel closer to native experiences.Follows a “native-first” approach, meaning the UI and performance mimic native apps. Ionic Uses HTML, CSS, and JavaScript with frameworks like Angular, React, or Vue.Builds apps as Progressive Web Apps (PWAs) or hybrid mobile apps.Renders UI components in a WebView instead of native APIs. Performance React Native: Better performance for apps that require complex animations or heavy computations.Direct communication with native modules reduces lag, making it suitable for performance-intensive apps. Ionic: Performance depends on the capabilities of the WebView.Works well for apps with simpler UI and functionality, but may struggle with intensive tasks or animations. User Interface (UI) React Native: Leverages native components, resulting in a UI that feels consistent with the platform (e.g., iOS or Android).Offers flexibility to customize designs to match platform guidelines. Ionic: Uses a single, web-based design system that runs consistently across all platforms.While flexible, it may not perfectly match the native look and feel of iOS or Android apps. Development Experience React Native: Ideal for teams familiar with React and JavaScript.Offers tools like Hot Reloading, making development faster.Requires setting up native environments (Xcode, Android Studio), which can be complex for beginners. Ionic: Easier to get started for web developers, as it uses familiar web technologies (HTML, CSS, JavaScript).Faster setup without needing native development environments initially. Ecosystem and Plugins React Native: Extensive library of third-party packages and community-driven plugins.Can access native features directly but may require writing custom native modules for some functionalities. Ionic: Has a wide range of plugins via Capacitor or Cordova for accessing native features.Some plugins may have limitations in terms of performance or compatibility compared to native implementations. Conclusion: Which One to Choose? Choose React Native if:You want high performance and a native-like user experience.Your app involves complex interactions, animations, or heavy processing.You’re building an app specifically for mobile platforms.Choose Ionic if:You need a simple app that works across mobile, web, and desktop.You have a team of web developers familiar with HTML, CSS, and JavaScript.You’re on a tight budget and want to maximize code reusability. Both frameworks are excellent in their own right. Your choice depends on your project’s specific needs, the skill set of your development team, and your long-term goals.