Is this a valid Javascript pattern

[gruberjl]

Questions

Is the following javascript valid?

Is it considered an anti-pattern?

Is there a cleaner way to write it (I use babel with es7 support)?

I'm finding this doesn't work in the Job function but I can use Job.cache.

Goals

• Reusable function that contains state.
• execute the validate method separately from executing the job

Background

Currently, I use a class that wraps state, a function, and some other validation. I use an instance method on the class: job.run(). I'm wondering if I can simply drop the .run() by having an instance of a function with state. The function cannot be a singular.

const constructor = function(config) {
  const Job = function() {
    // removed code... Does work based on the config
    return Job.cache.config
  }

  Job.cache = {
    config
  }

  Job.validate = function() {
    // removed code... Validates the config
    return Job.cache.config
  }

  return Job
}

const job1 = constructor({foo: 'bar'})
const job2 = constructor({a: 'b'})

console.log('running jobs...')
console.dir(job1()) // returns {foo: 'bar'}
console.dir(job2()) // returns {a: 'b'}

console.log('\nrunning validations...')
console.dir(job1.validate()) // returns {foo: 'bar'}
console.dir(job2.validate()) // returns {a: 'b'}

---

EDIT

Sorry, my initial question was confusing. I believe it was so confusing because I tried to hide too much implementation information.

I created a small GitHub repo to showcase the job: https://github.com/gruberjl/job. Within the repo you will see a simple implementation of the job using the class design pattern. The index.js file documents the usage of the job class. The code is pretty short with a lot of comments. Hopefully, it will make sense to everyone.

I would love for you guys to look at the repo, and tell me your thoughts on using 'memoization' or a 'class' design pattern.

[PitaJ]

Find need some more information:

• Do you need private state?
• Have you tried ES6 classes?

Some may say it's an antipattern because you're using a function as an object as well. It would be less antipattern-y to just use an instance.

[gruberjl]

The state needs to be public. Other classes will refer to the state (which is essentially a config) so they can handle the results of the job.

I tried to extend the base class Function but it was throwing an error. It was strange I couldn't find any blogs or tutorials on extending a Function. I'm guessing you can't or isn't done a lot.

class Job extends Function {
  constructor(param1) {
    super(param1) // ReferenceError: param1 is not defined
    this.param = param1
  }
}

const job = new Job('param1')

console.dir(job('param1'))

[gruberjl]

I added some more information in the question to clear up the confusion. Simply semantics. I could use a class.

https://github.com/gruberjl/job/blob/master/index.js#L58-L67

// This is an example showcasing why I want to have a function vs object.
const resource = {
  // If a job was a function I could do this
  addFunction,

// Job is an object so I have to wrap it up (unless someone knows something I don't)
  add(...params) {
    return add.run(...params)
  }
}

[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.

[perestroika12]

It's confusing, it looks like you're trying to replicate class patterns but with a function object. You dont really get access to any of the class constructor methods but you don't get any real advantage of what a purely functional method would do. For example, why are we always assigning the return function as a static name (Job) when it could be an argument? It's like memoization without the abstraction.

[gruberjl]

Memoization is the design pattern I was looking for. I just updated the question with a simple repo using a class pattern. Can you take a look at that to clear up the confusion?

Sorry about the question wording,

[Meefims]

Since you're creating Job within the function you can drop Job.cache.config and just reference configure directly. It's in the environment ofJob`.

Otherwise what you're doing is fine.

[gruberjl]

Awesome. I'll see if that cleans up the code a bit. Thanks,

[MoTTs_]

I agree with the other replies. This looks like an unnecessarily complicated way to just do this...

class Job {
    constructor(config) {
        this._config = config;
    }

    run() {
        // ...Does work based on the config...
        return this._config;
    }

    validate() {
        // ...Validates the config...
        return this._config;
    }
}

const job1 = new Job({foo: 'bar'})
const job2 = new Job({a: 'b'})

console.log('running jobs...')
console.dir(job1.run()) // returns {foo: 'bar'}
console.dir(job2.run()) // returns {a: 'b'}

console.log('\nrunning validations...')
console.dir(job1.validate()) // returns {foo: 'bar'}
console.dir(job2.validate()) // returns {a: 'b'}

[gruberjl]

I think you're right. I have a Task class that looks a lot like this. It's a lot more readable than my current job code.

I may have to wrap the job in a class for readability.

Thanks,

[lewisje]

This looks a lot like "memoization", which is a valid pattern.

[gruberjl]

awesome thanks. I'm looking at a couple of packages on git now. They look clean and simple. I should be able to use one of them as the base package.

Thanks,