Type-safe RPC between iframes. Call methods across frames like they're local functions. No glue code, no message parsing, no postMessage boilerplate. Works in both TypeScript and vanilla JavaScript. Types are optional. Use cases: - Micro-frontends communicating across domains - Embedded widgets (payments, auth, analytics) - Secure sandboxed apps Features: - Typed RPC over postMessage - Promise-based async calls - Automatic handshake + origin validation - Functional and OOP APIs - Works cross-origin, no server, no bundler required - ESM + CJS builds How it works: The child exposes an API. The parent connects via a secure handshake. All method calls are proxied over postMessage as typed async RPC. Why RPC-iFrame: If you work with iframes, you know the pain: raw postMessage, manual serialization, no types, origin checks scattered everywhere, zero error context when something breaks. RPC-iFrame replaces all of that with a single abstraction: typed RPC. You define an interface, expose it from the child, and call it from the parent. The runtime handles handshakes, security, and cleanup. GitHub: AdriAir/RPC-iFrame NPM: rpc-iframe #javascript #typescript #webdev #webdevelopment #programming #coding #opensource #npm #devtools #frontend #frontenddevelopment #softwareengineering #webarchitecture #iframe #rpc #indiedev #buildinpublic
More Relevant Posts
-
⚡ Why doesn’t setTimeout(fn, 0) run immediately? Most developers think JavaScript executes things in order… but that’s not always true. Let’s break it Example: console.log("Start"); setTimeout(() => console.log("Timeout"), 0); Promise.resolve().then(() => console.log("Promise")); console.log("End"); Output: Start End Promise Timeout What’s happening? JavaScript uses something called the Event Loop to handle async operations. Here’s the flow: Code runs in the Call Stack Async tasks go to Web APIs Completed tasks move to queues Event Loop pushes them back when stack is empty The twist: Microtasks (HIGH PRIORITY) • Promise.then() • queueMicrotask() Macrotasks (LOWER PRIORITY) • setTimeout() • setInterval() That’s why: Promise executes BEFORE setTimeout — even with 0ms delay Real takeaway: Understanding this can help you debug tricky async issues, optimize performance, and write better code. Have you ever faced a bug because of async behavior? #JavaScript #WebDevelopment #Frontend #Programming #Coding #Developers #100DaysOfCode
To view or add a comment, sign in
-
⚠️ JavaScript Mistakes Every Developer Should Know Even experienced developers make these mistakes… avoid them 👇 ❌ Using == instead of === 👉 Can cause unexpected results due to type conversion ❌ Forgetting return in functions 👉 Function runs but returns undefined ❌ Not handling asynchronous code 👉 Code executes before data is ready ❌ Mutating objects/arrays directly 👉 Can lead to unexpected bugs ❌ Ignoring this behavior 👉 this depends on how a function is called ❌ Using var instead of let/const 👉 Leads to scope-related issues 🔥 Key Takeaway: Small mistakes in JavaScript can lead to big bugs. Write clean and predictable code. 💬 Which mistake have you made before? #javascript #webdevelopment #frontend #coding #100DaysOfCode
To view or add a comment, sign in
-
-
𝐂𝐚𝐥𝐥𝐛𝐚𝐜𝐤𝐬 𝐚𝐫𝐞 𝐭𝐡𝐞 𝐫𝐞𝐚𝐬𝐨𝐧 𝐉𝐚𝐯𝐚𝐒𝐜𝐫𝐢𝐩𝐭 𝐜𝐚𝐧 𝐛𝐞𝐡𝐚𝐯𝐞 𝐚𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬𝐥𝐲 𝐝𝐞𝐬𝐩𝐢𝐭𝐞 𝐛𝐞𝐢𝐧𝐠 𝐬𝐢𝐧𝐠𝐥𝐞-𝐭𝐡𝐫𝐞𝐚𝐝𝐞𝐝. While revisiting some fundamentals today, I explored how 𝐜𝐚𝐥𝐥𝐛𝐚𝐜𝐤 𝐟𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐬 help JavaScript handle operations that would otherwise block execution. A callback function is simply a function passed as an argument to another function so that it can be executed later. This becomes important because JavaScript is 𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬 and 𝐬𝐢𝐧𝐠𝐥𝐞-𝐭𝐡𝐫𝐞𝐚𝐝𝐞𝐝. It has a single 𝐜𝐚𝐥𝐥 𝐬𝐭𝐚𝐜𝐤, often referred to as the 𝐦𝐚𝐢𝐧 𝐭𝐡𝐫𝐞𝐚𝐝, where every piece of code on a page gets executed. If a long or heavy operation runs on this thread, it 𝐛𝐥𝐨𝐜𝐤𝐬 𝐭𝐡𝐞 𝐜𝐚𝐥𝐥 𝐬𝐭𝐚𝐜𝐤, meaning nothing else can execute until it finishes. That’s why asynchronous patterns exist. What clarified this for me: • 𝐂𝐚𝐥𝐥𝐛𝐚𝐜𝐤𝐬 𝐞𝐧𝐚𝐛𝐥𝐞 𝐚𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬 𝐛𝐞𝐡𝐚𝐯𝐢𝐨𝐫 • APIs like 𝐬𝐞𝐭𝐓𝐢𝐦𝐞𝐨𝐮𝐭 allow tasks to run later • Heavy operations should never 𝐛𝐥𝐨𝐜𝐤 𝐭𝐡𝐞 𝐦𝐚𝐢𝐧 𝐭𝐡𝐫𝐞𝐚𝐝 • The call stack must remain free for smooth execution Another interesting detail is how 𝐞𝐯𝐞𝐧𝐭 𝐥𝐢𝐬𝐭𝐞𝐧𝐞𝐫𝐬 interact with memory. Every time an 𝐞𝐯𝐞𝐧𝐭 𝐥𝐢𝐬𝐭𝐞𝐧𝐞𝐫 is attached, it creates a 𝐜𝐥𝐨𝐬𝐮𝐫𝐞, which means it holds references to variables from its surrounding scope. Because of that, event listeners can consume memory if they are not managed properly. For example, attaching hundreds of event listeners (like onclick handlers for many buttons) can slow a page down because each listener holds its own closure and scope. Removing unused listeners allows 𝐠𝐚𝐫𝐛𝐚𝐠𝐞 𝐜𝐨𝐥𝐥𝐞𝐜𝐭𝐢𝐨𝐧 to reclaim that memory. Understanding this made me appreciate how callbacks, closures, and memory management are all connected in JavaScript. #JavaScript #SoftwareEngineering #DeveloperJourney #LearningInPublic #Programming #TechCommunity #WebDevelopment
To view or add a comment, sign in
-
-
🚀 TypeScript 6.0 is here — and it changes a lot. This isn't just a feature update. It's a bridge release preparing the ecosystem for TypeScript 7.0, which is being rewritten in Go for native speed. Here's what you need to know: ⚡ NEW DEFAULTS (your tsconfig will break) → strict: true by default (finally!) → module defaults to esnext → target defaults to es2025 → types defaults to [] — you must now explicitly set ["node", "jest", etc.] → rootDir defaults to the tsconfig.json directory 🆕 NEW LANGUAGE FEATURES → Built-in Temporal API types (stage 4 — date/time done right) → Map.getOrInsert() and getOrInsertComputed() types → RegExp.escape() types → dom.iterable is now merged into dom — no more separate lib entry needed → #/ subpath imports now supported in Node.js moduleResolution 🔧 BETTER TYPE INFERENCE → Functions that don't use `this` are no longer treated as contextually sensitive — fixing a long-standing quirk with method syntax in generic calls ❌ DEPRECATED (removed in TS 7.0) → target: es5 — use a bundler instead → --outFile — migrate to Webpack/Rollup/esbuild → --moduleResolution node / classic — use nodenext or bundler → --module amd, umd, systemjs → --baseUrl — add the prefix directly to your paths entries → import ... asserts {} — use with {} instead → module Foo {} namespace syntax — use namespace Foo {} instead 📦 THE BIG PICTURE TypeScript 7.0 (native Go port) is weeks/months away — not years. TS 6.0 is your migration checkpoint. Fix your deprecations now before 7.0 drops and removes them entirely. If you're upgrading, run tsc and address the warnings before 7.0 arrives. The ts5to6 codemod tool can handle some of the baseUrl/rootDir changes automatically. Are you migrating yet? 👇 #TypeScript #WebDev #JavaScript #Frontend #Programming
To view or add a comment, sign in
-
🚀 Harness the power of JavaScript Promises to handle asynchronous tasks like a pro! 🌟 Promises are objects that represent the eventual completion or failure of an asynchronous operation. Simply put, they help you manage the flow of your code when dealing with time-consuming tasks. For developers, mastering Promises is crucial for writing efficient and scalable code, ensuring smooth execution of operations without blocking the main thread. Let's break it down step by step: 1️⃣ Create a new Promise using the new Promise() constructor. 2️⃣ Within the Promise, define the asynchronous operation you want to perform. 3️⃣ Resolve the Promise with the desired result or Reject it with an error. Here's a code snippet to illustrate: ``` const myPromise = new Promise((resolve, reject) => { // Asynchronous operation let success = true; if (success) { resolve("Operation successful!"); } else { reject("Operation failed!"); } }); myPromise .then((message) => { console.log(message); }) .catch((error) => { console.error(error); }); ``` Pro Tip: Always remember to handle both the resolve and reject outcomes to ensure robust error management. 🛠️ Common Mistake: Forgetting to include the .catch() method to handle errors can lead to uncaught exceptions, so be sure to always implement error handling. ❓ What's your favorite use case for JavaScript Promises? Share in the comments below! 🌐 View my full portfolio and more dev resources at tharindunipun.lk #JavaScript #Promises #AsyncProgramming #WebDevelopment #CodeNewbie #DeveloperTips #LearnToCode #TechCommunity #BuildWithDevSkills
To view or add a comment, sign in
-
-
Stop writing your own Zod schemas and TS interfaces. 🛑 I just launched **API Mock UI** — a lightweight IDE that turns any JSON response into production-ready code in seconds. Why I built this: • Copy-pasting JSON is fast; typing interfaces is slow. • MSW handlers should be generated, not hand-coded. • Visualizing data structures helps catch errors early. Give it a spin (it's free and open source): 🔗 https://lnkd.in/g72p5W3g Let me know what you think! 🚀 #frontend #javascript #programming #tools
To view or add a comment, sign in
-
-
JavaScript is a single-threaded language, which means it executes one task at a time using the call stack. But it can still handle asynchronous tasks like API calls, timers, and promises. This happens because of the Event Loop. The Event Loop continuously checks if the call stack is empty. When it is empty, it takes tasks from the callback queue and moves them to the stack to be executed. Because of this system, JavaScript can run asynchronous operations without blocking the main thread, which makes web applications faster and more responsive. Learning the Event Loop helped me understand how JavaScript manages asynchronous code behind the scenes. #JavaScript #Coding #EventLoop #async
To view or add a comment, sign in
-
-
🚀 Simplifying API Calls in Redux with createAsyncThunk. Earlier, we had to write too much boilerplate for API calls in Redux. Handling: #loading #success #error …meant creating multiple action types, action creators, and reducers. Then I started using createAsyncThunk from Redux Toolkit 👇 It automatically generates: #pending #fulfilled #rejected So instead of writing everything manually, you just focus on the async logic. Example: export const fetchUsers = createAsyncThunk( "users/fetchUsers", async () => { const res = await fetch("https://lnkd.in/g27u5z_N"); return res.json(); } ); And handle states cleanly in extraReducers. 🔥 What I like about it: Reduces boilerplate significantly Makes async flow predictable Cleaner and more readable code 💬 What do you use for API calls in your projects? #React #Redux #Frontend #WebDevelopment #JavaScript #WebArchitecture #SoftwareEngineering
To view or add a comment, sign in
-
https://lnkd.in/d8z5wQ5e - Most devs think a Hex Calculator is a one-liner `toString(16)`, but the edge cases will bite you. As a Frontend Engineer building with TypeScript and Next.js 15, I’ve learned that "simple" tools often hide the most complexity. 🧠 I remember years ago debugging a color picker where my bitwise operations failed because I ignored how JavaScript handles signed integers. It was a mess. 🛠️ When I started building this tool for my platform, I didn't want a "good enough" solution. I used GitHub Copilot to scaffold the initial logic, but it actually struggled with high-precision overflows beyond the standard 32-bit range. 🔢 So I went back to basics, refining the algorithms in a dedicated TypeScript utility layer to handle everything from large-scale addition to bitwise shifts. The UI is styled with Tailwind CSS for that crisp look, while Vite kept the local dev experience lightning-fast during the build process. ⚡ I ran the entire logic through Vitest to ensure that edge cases—like negative hex values—were handled perfectly before shipping. 🧪 Finally, I pushed it to Vercel to ensure the 300+ tools on Calculator All stay fast for everyone worldwide. 🚀 It’s a reminder that even "solved" math problems deserve a modern baseline of quality and testing. 🏗️ Building tools for millions of users means you can't leave precision to chance. 💻 What’s the weirdest bug you’ve ever found when working with Hex or binary conversions? #HexCalculator #FrontendEngineer #TypeScript #ReactJS #NextJS #WebDev #Programming #SoftwareEngineering #CodeTips #Vercel #TailwindCSS #Vite #Mathematics #CalculatorAll #DevLife
To view or add a comment, sign in
-
-
🧠 Tired of messy async code like callbacks inside callbacks? That’s exactly why Promises exist. 🔹 What is a Promise? A Promise represents a value that will be available: - Now ❌ - In the future ✅ 🔹 Promise States A Promise has 3 states 👇 1️⃣ Pending → Initial state (still waiting) 2️⃣ Fulfilled → Task completed successfully 3️⃣ Rejected → Task failed 🔹 Example const promise = new Promise((resolve, reject) => { let success = true; if (success) { resolve("Task completed"); } else { reject("Task failed"); } }); promise .then((result) => console.log(result)) .catch((error) => console.log(error)); 🔹 Why Promises? Without Promises: ❌ Callback hell 😵💫 With Promises: ✅ Cleaner code ✅ Better error handling ✅ Easier async flow 💡 Key Idea - A Promise is a placeholder for a future result. 🚀 Takeaway - Promises handle async operations - They make code readable - They avoid nested callbacks Next post: Async/Await Explained Simply 🔥 #JavaScript #Promises #AsyncJS #Frontend #WebDevelopment #LearnJS #Programming #LearningInPublic
To view or add a comment, sign in
-
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development
This looks like a really solid solution for the iframe headaches we've all dealt with. The type safety aspect alone would save so much debugging time in complex micro-frontend setups.