I don't write a lot of JavaScript. A product I work on uses several JavaScript libraries for rendering fancy client-side controls of different types. We've been known to switch libraries. So what I'm doing is writing some initializer functions that wrap the libraries' initializers. That way, if we jump ship to some other plug-in for a control, I hopefully only have to change the definition of the adapter. Fine.

Most of these things seem to follow a pattern of taking a single parameter: an object with various fields for the options. For instance, one might take an object like this:

{ allowMultipleEntries: true, minimumLength: 3, maximumLength: 60, }

function fancyControlWrapper(controlId, additionalOptions) {
	//defaults for this plug-in
	var options = {
		allowMultipleEntries: true,
		minimumLength: 3,
		maximumLength: 60,
	};

	if (typeof additionalOptions == 'object') {
		options = Object.assign(options, additionalOptions);
	}

	var baseControl = document.getElementById(controlId);
	$(baseControl).fancyControlInitializer(options);
}

10/31/2017 10:22:27 AM

This sounds like a bad situation. Code with more than a couple of libraries usually grows into an unmaintainable monstrosity and then questionable ideas like wrapping the wrappers come into play.

In theory, I don't see why what you're talking about wouldn't work.


If it was me, I'd probably pass in a name of what I was about to initialize in addition to the additionalOptions, then just put in an if statement to do the right one. That way you could set all your defaults in a common place, and only optionally override those defaults with additionalOptions.


Really it sounds like it's time to do some cleanup refactoring.

11/1/2017 11:39:58 PM

I guess it's a bad situation, but I don't feel the pain that much. The base application brings all that baggage, but I'm only working on a plug-in. That does mean that I don't have a lot of influence on when and what to clean up, though.

So you're saying add a parameter for the control type and have, like, a big switch statement? I don't think that really saves me any trouble. I still have to go replace the initializers, and there isn't really any common code that belongs in a common initializer. Is there another benefit I'm not seeing?

11/2/2017 6:53:09 AM

I don't see a problem with this.

Only thing is if `allowMultipleEntries` is renamed and you override it with `multiple` then the first property is still sitting in your base options, which probably isn't a big deal... but you could imagine a scenario where you don't want to pass the original.

11/5/2017 9:31:57 AM

I'd probably break it up so the default setting logic isn't tied to the specific control.

// option one OO like
var ctrl = control(id).defaults(defaults);
ctrl.fancyControlInitialize.call(ctrl,options);

// option two functional like
control(id).fancyControlInitialize.call(null,merge(defaults, options));

11/5/2017 11:01:30 AM

EuroTitToss said:

Quote :

"Only thing is if `allowMultipleEntries` is renamed and you override it with `multiple` then the first property is still sitting in your base options, which probably isn't a big deal... but you could imagine a scenario where you don't want to pass the original."

Yeah, I didn't really describe the current state of things accurately. When I'm able to standardize the set of control options the application requires, there won't be any reason to merge option objects anymore. Instead, the initializers will just set the library-specific settings based on the values of the standard properties passed in the standard options provided as an optional parameter in the initializer.

But right now, I'm using this fancy table plugin with some options that I know should be the defaults, and I'm overriding certain values on specific calls. So there's information about the plugin leaking into the callers, but it's quick and easy today to just merge the option objects.

Tomorrow (or sometime), it's going to be stricter. I'm gonna say, like, any table plugin we use must support pagination. The setting you will use to set the number of rows per page will be called rowsPerPage. We're gonna set an application default for that in the initializer for the control. If you want to override that default, you're welcome to do it by setting the rowsPerPage property in the options object you pass to the initializer.

In the initializer, the current plugin expects rowsPerPage. So my default options include that property with the application's default value, and since the property names are the same, it's simpler just merge the default & caller-provided options.

But the next plugin will expect a setting called paginationRows. Callers won't need to do anything. Instead, I'll change the initializer to explicitly set paginationRows to the value of the caller's rowsPerPage property. The merge will disappear completely. Hell, it could disappear completely now--it was just expedient for me. Make sense?

CaelNCSU said:

Quote :

"I'd probably break it up so the default setting logic isn't tied to the specific control. <snip> That way it reduces the boilerplate of initializing the defaults."

There isn't any boilerplate. The defaults per control type (e.g. our date input) would be declared in the initializer for that control type. That's the only place they'd be defined.

11/7/2017 9:24:09 AM

If you do this:

        if (typeof additionalOptions == 'object') {
		options = Object.assign(options, additionalOptions);
	}

11/7/2017 10:31:08 AM

Well, maybe I could make a decorator or some shit and transpile to whatever fuckin' garbo IE11 implementation we might need. I'm not super worried about that.

11/7/2017 1:13:42 PM

I recently upgraded a JavaScript library for a control and was very glad I took this approach earlier.

2/5/2019 7:39:20 AM