The CLF, or Class-Listener-Function, approach
The CLF, or Class-Listener-Function approach I'm exploring in my latest development bucks the recent trend for including the kitchen sink and, instead, focusses on creating a well-optimised, easily-debugged, single JavaScript file with four listeners and four functions that are triggered by four classes placed, in any combination, on actionable elements on the page. I simply include the 'listenFor____' class of the event type I'm waiting to have happen on the element (whether button, a, img, or any other type of element) and give it an ID (which can easily be changed to name, or some other element attribute).
The current four classes are called 'listenForClick', 'listenForChange', 'listenForKeyUp' and 'listenForBlur'.
Some combination of these four classes, along with their listeners and associated functions (with a select case per calling element ID to actually do whatever I want it to do) handle the entirety of the JavaScript in my latest development.
So far it seems like a neat, easily-navigable and easily-optimizable event-driven way to approach the growing frustration of requiring an entire build process to do just about anything, and wanting access to the behaviour of any part of the site as quickly as possible (full disclosure, there's still a build process).
Possibly, as the development grows in complexity over the coming days and changes happen, my attitude toward this approach might change. I'll keep it lean and modular so, no matter what happens along the way, I'll avoid boxing myself in as much as possible. Both positive and negative developments will be outlined here so, at least in the worst case scenerio, some might be fore-warned if it turns out to be a mistaken approach.
As a final note, I'm aware this JavaScript file could become quite large...but, I'm thinking, compared to a folder full of components and a Vuex store to pass everything around, and with the added ease of IDE's code-folding making code-organisation a breeze, it seems too fast and easy a way to develop to not explore, so I'll have a look, see how I get on and update this post in a few days.
The current four classes are called 'listenForClick', 'listenForChange', 'listenForKeyUp' and 'listenForBlur'.
Some combination of these four classes, along with their listeners and associated functions (with a select case per calling element ID to actually do whatever I want it to do) handle the entirety of the JavaScript in my latest development.
So far it seems like a neat, easily-navigable and easily-optimizable event-driven way to approach the growing frustration of requiring an entire build process to do just about anything, and wanting access to the behaviour of any part of the site as quickly as possible (full disclosure, there's still a build process).
Possibly, as the development grows in complexity over the coming days and changes happen, my attitude toward this approach might change. I'll keep it lean and modular so, no matter what happens along the way, I'll avoid boxing myself in as much as possible. Both positive and negative developments will be outlined here so, at least in the worst case scenerio, some might be fore-warned if it turns out to be a mistaken approach.
As a final note, I'm aware this JavaScript file could become quite large...but, I'm thinking, compared to a folder full of components and a Vuex store to pass everything around, and with the added ease of IDE's code-folding making code-organisation a breeze, it seems too fast and easy a way to develop to not explore, so I'll have a look, see how I get on and update this post in a few days.
Category: Coding