J World

As web developers, we constantly work with objects. We receive data, manipulate it, pass it around, and often need to create new objects based on existing ones, perhaps adding, modifying, or, critically, omitting certain properties. You might get a user object from a database that includes a sensitive password field, but you only want to send the user’s public profile data to the frontend. Or you might have an internal configuration object with fields relevant only to server-side logic, which you want to strip before passing the config to a client-side context. So, how do you efficiently and cleanly create a new object that contains almost all the properties of an old one, except for a select few? If you’ve seen or used syntax like this: const userData = { id : 123 , username : 'developer' , email : 'dev@example.com' , password : 'hashedpassword123' , // Sensitive! createdAt : '...' , }; // We want a new object without 'password' co...

The landscape of web development is ever-evolving. Frameworks rise and fall, build tools change seasons, and the core languages we use continue to mature and adapt. As developers, staying attuned to these shifts isn’t just about chasing the latest trend; it’s about understanding where the industry is heading, spotting opportunities, and preparing our skill sets for the future. Looking ahead to 2025, the core pillars of web development remain strong, but several technologies are demonstrating significant growth, gaining new capabilities, and becoming increasingly relevant for modern web applications, from front-end heavy experiences to high-performance back-end services and everything in between. What makes a language “one to watch”? It’s usually a combination of factors: Growing adoption: More projects, jobs, and developers are using it. Ecosystem maturity: Better tools, libraries, and community support. Performance improvements: Significant steps in speed or efficiency. New feature...

You’re building a NestJS application, perhaps deploying it or just running a production build locally, and you hit a roadblock during startup. Your console logs an error message like this: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with . catch (). The promise rejected with the reason : Error : ENOENT : no such file or directory, stat '/Users/jay/Projects/test/server/dist/i18n/' at async stat ( node :internal/fs/ promises : 1032 : 18 ) at async exists ( /Users/ jay/ Projects /test/server/node_modules/nestjs-i18n/src/utils/file. ts : 6 : 13 ) ... ( Rest of the stack trace) at async I18nModule. onModuleInit (...) at async NestApplication . init (...) at async NestApplication . listen (...) at async bootstrap ( /Users/ jay/ Projects /test/server/src/main. ts : 48 : 3 ) // <- Your application entry point The core of the error is clear: E...

  If you’ve started using RTK Query for managing your API requests in Redux, you’ve definitely encountered the baseQuery option within your createApi setup. For most common scenarios involving standard REST APIs, you’re directed towards using fetchBaseQuery: import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react' ; export const myApi = createApi ({ reducerPath : 'myApi' , baseQuery : fetchBaseQuery ({ baseUrl : '/api' }), // <-- You use fetchBaseQuery here endpoints : ( builder ) => ({ // ... your endpoints ... }), }); This works like magic! It takes care of sending HTTP requests, handling responses, and fitting everything into RTK Query’s caching and state management layer. But as you delve deeper, perhaps looking at advanced examples or exploring custom integrations, you might stumble upon documentation or type definitions mentioning BaseQueryFn. You might wonder: How does this relate to fetchBaseQuery? Are they differe...

Handling dates and times in software seems simple until your application crosses borders. A seemingly straightforward format in one country can be completely alien in another. Dates can be written MM/DD/YYYY, DD/MM/YYYY, or even YYYY/MM/DD. Times might use a 12-hour clock with AM/PM, or a 24-hour format. Getting this wrong can lead to confusion, misinterpretation of data, and a poor user experience. If your application serves users in diverse regions like Korea, the United States, Vietnam, and Japan, understanding and implementing locale-specific date and time formatting is crucial. Let’s dive into the standard conventions for these four countries and explore how to implement them using common JavaScript tools. 🗓 Understanding the Differences: A Quick Look While many countries use variations of DD/MM/YYYY or MM/DD/YYYY, our focus regions cover some distinct styles, particularly around the year (YYYY) placement and separators. Here are common formats you’ll encounter (focusing on Y...