Within a class, you can define methods, which are functions associated with the class and its instances. These methods are sometimes referred to as 'class methods.'
We have a User class with a method called fetchData. When we pass user.fetchData as an event listener callback, it throws an error saying 'cannot read property of undefined (reading this)'. How would you fix this, and why does it happen?
Imagine you are building a utility class for mathematical operations. You want to call a helper method like MathUtils.clamp(val, min, max) without having to instantiate the class with the 'new' keyword. How would you define that method in JavaScript, and what happens if you try to access 'this' inside it?
In our Node.js codebase, some developers write class methods as standard methods like 'foo() {}' and others write them as arrow functions like 'foo = () => {}'. If we are instantiating this class thousands of times in a high-throughput loop, what are the performance and memory implications of these two approaches?
You are debugging a subclass that overrides a parent class's method. The parent class defines the method as an arrow function property, but the subclass tries to override it using standard prototype syntax. Why is the subclass's override being ignored, and how would you resolve this?
We are designing a core SDK that will be distributed to third-party developers. We need to decide between exposing our APIs via static class methods versus instantiable classes with prototype methods. What architectural tradeoffs would you consider regarding testability, tree-shaking, and state management?
We have a legacy codebase heavily reliant on ES6 classes with deep inheritance chains. We're seeing memory leaks in production because instances aren't being garbage collected due to bound event listeners. How would you audit this class structure and refactor it to use a more memory-efficient pattern without rewriting the entire application?
Your team is maintaining a large-scale enterprise application built on a class-based framework. You want to migrate the team toward a more functional, composition-over-inheritance architecture to improve tree-shaking and testability. How do you design a migration path that avoids a complete rewrite while keeping the system stable?
In a micro-frontend architecture where multiple independent teams load their own bundles, we've run into issues where shared utility classes instantiated across different bundles don't share the same prototype chain or static state. How would you architect a solution to ensure singleton behavior or consistent class evaluation across federated module boundaries?