function Hello() {
// other stuff
const callback1 = () => {
// do stuff
}
// other callbacks, effects, etc
return <button onClick={callback1}>{label}</button>;
}
See how the callback functions, and everything else, is defined before the "rendering" part of the function? Compared to, say: function Hello() {
const render = () => <button onClick={callback1}>{label}</button>;
const callback1 = () => {
// do stuff
}
// other callbacks, effects, etc
return render();
}
That uses the Most Significant Function First approach, where the higher-order function (render) is defined first, and the functions it depends on are defined after them.That latter example, AFAIK, compiles fine (filling in the elided etcs, of course).
To me, MSFF reads better. The higher order function being defined first gives the reader a lay of the land. They provide the highest overview of what the module as a whole does. The functions that follow drill down into increasingly finer details.
LSFF is backwards, forcing the reader to understand the finer details of a module without having any clue about their context or the overarching goal until the very end of the code.
React specifically, as a reader, I want to know first "What are we rendering?" Only then do I want to then know where the data that goes into that render comes from, the processing of that data, and what user interactions there may be.
I see LSFF a lot, especially in React code. Maybe it's just a personal preference, but I just feel like most coders are jumping straight to the "render" part of the code anyway, before looking at the rest of the module. So why write it at the bottom? Why not write the code the way it should be understood?