Looking up objects outside of state

[esatterwhite]

There is a common pattern emerging with default values for chain actions that has exposed a pain point with the lookup function

const defaults = {
  name: '!fullname'
, slug: '!slugify(#name)'
}

module.exports = person

async function person(opts) {
  return this.lookup({
    ...defaults
  , ...opts
  })
}

calling this function, I would generally expect this to "just work", but the slug value is never populated

await chain
  .person()
  .execute()

// { name: 'Bob Jones', slug: '' }

The problem here is that the lookup function assumes that all values exist in state, however in the case of defaults above, that is not true. As a work around people will generally (ab)use .set to work around this short coming

await chain
  .set('name', '!fullname')
  .person({
    name: '#name'
  })
  .execute()

// { name: 'Bob Jones', slug: 'bob-jones' }

Workable, but not every intuitive and a bit clunky. What we could do is either

1. fallback to reading values from the current object context if not found in state
2. introduce a new operator to reference "this" object, @ for example
3. add something to the compiler to understand a keyword

this operator

const defaults = {
  name: '!fullname'
, slug: '!slugify(@name)'
}

this keyword

const defaults = {
  name: '!fullname'
, slug: '!slugify(#this.name)'
}

[esatterwhite]

this feels really javascript-y and I would try to use that to do things I know i shouldn't. maybe that is mis leading.

#self.thing ? is self a little too on the nose?

[esatterwhite]

It would need to be both a token an apart of the lookup rule such that it can only be present as the first part of a lookup. It isn't an identifier

valid

#self.thing

not valid

#self.foo.self.bar

valid

!foo:#self.foo

[esatterwhite]

self is also a valid identifier. while this, its much less likely to show up in object keys or values.

it also makes it a token that is parsed + consumed, removing it from being abused as a language feature

valid

!foo(#this.bar.x)

not valid

!foo(#this.bar.x.this)

so calling it this removes the potential from someone trying to abuse the object traversal and pluck things off the prototype chain and do bad things.

[darinspivey]

What do you mean by on the nose? I have always liked self. I agree that the word this is potentially confusing.

[esatterwhite]

Just calling not this for the sake of not calling it this.

[esatterwhite]

fallback to reading values from the current object context if not found in state

I guess the question becomes which value takes priority? the current behavior is always read from state. to avoid a breaking change it would need to be

1. check global state
2. check current lookup value / context

[esatterwhite]

We ended up going with this as it feels a little more natural in the language, it also inherently prevents people from doing dirty things with the this key word which may have previously been possible.

As a result, a look up value can use this to reference data in the current execution context. other than that, it behaves just as it did before

  chain
    .lookup({
      key: 'world'
    , alt: 'bill'
    , name: 'hello {{#this.key}} {{#this.alt}}'
    , output: '!template:#this.name'
    , array: [{
        deep: 'yes'
      , works: '#this.deep'
      }, {
        deep: 'no'
      , works: '#this.deep'
      , templated: '!template:"templated {{#this.deep}}"'
      }]
    , pluck: '#this.array.0.works'
    , nested: {
        objects: {
          here: 'there'
        , there: '#this.here'
        }
      }
    })

yields

{
  key: 'world',
  alt: 'bill',
  name: 'hello {{#this.key}} {{#this.alt}}',
  output: 'hello world bill',
  array: [
    { deep: 'yes', works: 'yes' },
    {
      deep: 'no',
      works: 'no',
      templated: 'templated no'
    }
  ],
  pluck: 'yes',
  nested: {
    objects: { here: 'there', there: 'there' }
  }
}