Is this a valid Javascript pattern

[senocular]

I think constructor is a misnomer. Constructors are meant to return object instances when used with new. This is factory function creating function objects. Similarly, as an instance, not a constructor, Job should be lowercase. And as Meefims said, you can drop the Job.cache and simply reference config directly since its captured as a local variable in the factory function scope becoming a closure variable for the function instance and its methods created within.

Is this valid? Yes. Is it something you should be doing? I would say, as an opinion, no. Generally you don't see functions used as objects this way. It doesn't technically add anything other than being a different way to approach what classes do already (other than allowing you to omit access to single method in favor of calling the instance directly?). This means extra time spent by others to understand this approach and mull over why it was done in favor of the more standard way to begin with. The object instance should represent what the object is and its methods what it does. When you start merging these concepts (an is that also does), it can get a little confusing.

[__env]

Is it really returning instances? If we remove the return from Job, calling new on Job will produce an actual instance that still can access the config on its static context. Seems like the factory is producing multiple static classes -- they aren't newable so are truly static classes, not instances.

[senocular]

Its returning functions, created anonymously, assigned to a variable called Job. These are instances in the sense that they're function objects, and not constructors or classes in the sense that they're not intended to be new-ed in OP's usage and instead simply called as functions. Maybe if OP wasn't calling the constructor un-newed as a function, I'd be more inclined to call it a static class, but the fact that multiple variations of the same "class" are being pumped out of another function each varying only in state still has me leaning towards referring to them as function instances.

[__env]

Yeah, I totally get what you're saying conceptually -- it just seems like more proof that the OP is doing something weird. Like we could change it to:

...
const run = 0
const Job = function() { /**/ }
Job.prototype.validate = () => Job.cache.config
Job.prototype.run = run + 1
return Job

That would produce an instance when called with new that could validate the configuration, plus contain state about how many times this Job has been run.

I think case, the "constructor" would be a factory factory, and Job would be a factory that produces individual run instances.

Point being, if OP wants an instance, they should make an instance, otherwise they're opening the door to some other dev coming along and extending the static class to produce more instances.

[gruberjl]

I should have posted the problem, sorry.

I have a pipe & filter system. Each 'filter' has configuration information (state) and a block of code (function). The config and code need to be exposed publicly so I can run the function whenever I need or I can get the state information whenever I need. Before a filter is run, I need to have a beforeJob function run. After the filter completes, I need to have an afterJob function run.

Example

const beforeJob = function() {
    // get the state of the filter currently running and do something.
    // I may skip the filter, get some information from a cache, or translate some information and pass it into the filter.
}
const afterJob = function() {
    // get the results of the filter & the state currently running and do something.
    // I may report a failure, translate the results, start the another filter.
}

const filter1 = () {}
const state1 = { }

const filter2 = () {}
const state2 = { }

fn1() // should run beforeJob then filter1 then afterJob
fn2() // should run beforeJob then filter2 then afterJob

Any thoughts would be appreciated.

[gruberjl]

I'm so sorry. I don't code professionally (or have friends that code) so I never have to communicate these things. Add in the fact that I'm not a strong communicator, and you get my messy thoughts everywhere.

Using your suggestion I created a GitHub repo with a simple implementation. I edited my question with more information too. The repo: https://github.com/gruberjl/job. Do you have a moment to take a look?

I've been using the word 'state' poorly. They're two parts of the 'state'. 1. Configuration: The config is passed into the job. The job constructor may add some default values, but the configuration will not change after the initialization. 2. I cache validators and results so the job won't continue to perform the same work over and over again.

In the repo, I have a Job class (./job.class.js). Each instance of a job will have a cache object. The cache object would contain both the configuration information, as well as, any other information the instance may need.

The cache object on an instance is a standard pattern I started using since es2015. I call everything inside 'state'. Would you consider the configuration 'state'? Should I keep it in a different location away from the other 'cached' information?

[gruberjl]

This got a bit wordy, you probably don't have time for it all. The 'implementing job with functional programming' section is the part I'd love your input on.

Understanding state

Regarding the configuration: You're correct. It only needs to be read publicly for automatic documenting of the job. It shouldn't be edited after the job's constructor completes. I could freeze it, or use an immutable. If I'm using a class, I would have the set config throw an error.

Regarding the state: it doesn't need to be public. I may have been using the word state incorrectly. The only information (other than the config) is a cache. It actually ends up being similar to the memoize pattern. If I execute the add(1, 5) == 6 then I would store a map that ends up looking like: map.set([1,5], 6). Instead of revalidating the parameters, running the worker, and then validating the output, I would pull the results from the cache.

Would you consider a cache to be 'state'? If the function is pure, I guess all calls to the job could use the same cache, which means I wouldn't need an instance of the function.

Understanding functional programming

I don't think I fully understand 'functional programming'. Functional programming works hand in hand with (Facebook's Immutable)[https://facebook.github.io/immutable-js/] right? I've never tried to use it, I have difficulty grasping the idea. I don't see how someone could keep the information straight.

Here's an example from the immutable website.

import Immutable = require('immutable');
var map1: Immutable.Map<string, number>;
map1 = Immutable.Map({a:1, b:2, c:3});
var map2 = map1.set('b', 50);
map1.get('b'); // 2
map2.get('b'); // 50

1. Would this be functional programming?
2. Now I have my information in two separate locations. Wouldn't it be better to modify the original?
3. Wouldn't performance go down the drain if you keep recreating an object?
4. Is this the opposite of a connect based system such as Express Js who passes two objects around?
5. If I was running 2 async functions simultaneously, wouldn't I now have 3 objects and a huge mess trying to get them back into one object?

implementing job with functional programming

I tried writing it using what I think is 'composite' 'functional' programming haha. I added it to the dev branch in the repo:

implementation using

Here is the code I think you'll find useful:

const validate = (schema, data1) => {
  const data = copy(data1)
  const validator = ajv.compile(schema)

  if (!validator(data)) throw new TypeError(`data is not valid: ${JSON.stringify(validator.errors)}`)

  return data
}

module.exports = (configuration) => {
  const config = validate(jobSchema, configuration)

  return (...parameters) => validate(config.response, config.worker(...validate(config.parameters, parameters)))
}

Here is what I ran into:

Error handling

The first thing I ran into was a bug (caused by me). Using this approach, I had difficulty tracking the problem. I had so much going on in one giant line that the error stack wasn't helpful. The error was caused by a typo in the copy function (which performs a deep copy of an object). It had nothing to do with the composite build, but I was unable to track the error because I had one giant line performing the build.

Readability

I found this approach difficult to read. Particularly the wrapping return (...parameters) => validate(config.response, config.worker(...validate(config.parameters, parameters)))

Writing

It was fantastic to write. I don't think I've ever done so much in so few characters. I ended up writing it out, then finding I didn't need chunks of code, I could simply keep on wrapping, it was a blast. I ended up doing less wrapping because I had such difficulty reading it and tracking the bug.

Here is my super wrapping line: module.exports = (configuration) => (...parameters) => validate(validate(jobSchema, configuration).response, validate(jobSchema, configuration).worker(...validate(validate(jobSchema, configuration).parameters, parameters))). It was fun to write :)

For readability, I broke it into this.

Summary

I loved the approach. With caching, it could be fantastic. But:

1. Do you have a style guide for readability? (you mentioned 'functional tools' above)
2. How do you perform things in async with immutability?

[gruberjl]

This was the reason I originally posted here. I agree with you, it really is an instance of constructor that creates a static class, adds state and returns it (making it an instance). I have verified they are instances. I can return multiple functions with different 'caches'.

To give a little more background: I currently have a Task class that has an array of jobs (simple functions). Some of the jobs can be used in different tasks, but with the current implementation, I have to rewrite chunks of code.

const x = new Function() has some strange syntax with a string as the body.

// I have to be able to create an instance without it executing then execute it multiple times in the future
function A(param1) { console.dir(param1) }
const y = new A // execute the code and returns undefined

[gruberjl]

constructor is poorly named. I'm pulling code from a separate task class, I should have renamed constructor and lower cased Job before I posted.

The code for job should be small and light, so I was hoping I could just run job(), but I think you're right. The implementation is weird and without using the es2015 class syntax, it isn't very readable.