A programming language is said to have First-class functions if functions in that language are treated like other variables.
So the functions can be assigned to any other variable or passed as an argument or can be returned by another function.
JavaScript treats function as a first-class citizen. This means that functions are simply a value and are just another type of object.
We have an array of user objects and we need to format their names and filter out inactive ones. How would you pass formatting functions directly into '.map()' and '.filter()' instead of writing inline arrow functions every time?
Imagine you're building a simple button click handler. You want to pass a function 'logClick' to 'addEventListener', but you need it to log a specific button ID. How would you write a function that returns another function to capture that ID?
We're refactoring a legacy codebase where we have a lot of repetitive API fetching logic. How would you design a higher-order function wrapper that takes a standard fetch function and automatically adds retry logic or logging to it?
A developer on your team passed an object's method as a callback to a third-party event emitter, but when it executes, 'this.state' is undefined. What's happening under the hood with JavaScript's function handling here, and how would you fix it?
In a React application, we're seeing performance degradation because handlers are being recreated on every render, breaking 'React.memo' downstream. How do you balance the use of inline closures versus stable function references, and how would you design a custom hook to solve this cleanly?
We are building an Express-like middleware pipeline for a custom Node.js gateway. How would you design the composition engine that chains these middleware functions together, ensuring they execute sequentially and can halt the chain?
Our engineering org is debating migrating our core SDK from an object-oriented class-based architecture to a functional, composition-based approach using first-class functions. What are the long-term maintenance, bundle size, and API extensibility trade-offs of this architectural shift?
We have a high-throughput Node.js microservice processing millions of events per minute. We've noticed a high garbage collection overhead traced back to short-lived closures and higher-order functions generated dynamically. How would you audit this and re-architect the hot paths to mitigate memory churn without sacrificing code readability?