#JSDoc question for annotating a wrapper method to get VSCode completions

56 messages · Page 1 of 1 (latest)

hardy shore
#

I have a ES2015 style prototype class.

/**
 * @constructor
 * @param {Internal.RecipesEventJS} e
 * @param {(InputItem_|Internal.InputFluid_)[]} inputs
 */
function CVIPressurizingWrapper(e, inputs) {
  this.e_ = e
  this.inputs_ = inputs

  this.secondaryFluidInput_ = null
  this.secondaryFluidResult_ = null

  this.processingTime_ = 40
  this.heatRequirement_ = null
}
...
// other chainable methods below

It's annyoying to require an e for every instance of construction, so I have a helper to do partial appliation on the constructor, except it returns a instantiated instance of the class.

/**
 * Returns a concrete instantiation of the given constructor with the
 * RecipesEventJS context applied as the first argument.
 * @param {Internal.RecipesEventJS} e
 * @param {Function} constructor
 * @returns {Function}
 */
const getConstructorWrapper = (e, constructor) => {
  return function () {
    const args = [constructor, e]
    for (const arg of arguments) {
      args.push(arg)
    }
    const newclass = constructor.bind.apply(constructor, args)
    return new newclass()
  }
}

Which lets me alias it as follows:

ServerEvents.recipes(e => {
   /**
    * @callback {CVIPressurizingWrapperCB}
    * @param {(InputItem_|Internal.InputFluid_)[]} inputs
    * @returns {CVIPressurizingWrapper}
    */
  /**
   * @type {CVIPressurizingWrapperCB}
   */
  const pressurizing = getConstructorWrapper(e, CVIPressurizingWrapper)
})

The actual code I have is a lot more complex, I'm summarizing the gist of how it works here. pressurizing is now a function that takes inputs and returns a concrete instance of the class (no need for new). However, my completions don't work. This is the best way to annotate this AFAICT from SO. Annotating pressurizing with /** @param */ directly does not work either. Has anyone done anything else like this?

marsh turtleBOT
#

Once your ticket has been resolved, please close it with </ticket close:1054771505520717835> command!

glacial yew
hardy shore
#

I made a whole post about why I'm not doing a recipe schema for this LOL.

#

I have a recipe schema for this recipe type already. It just does something stupid, so I am wrapping it with a wrapper class.

glacial yew
#

i know, recipe schema without addon is painful

hardy shore
#

quality meme though

# 
e.register(
  'vintageimprovements:pressurizing',
  new $RecipeSchema(
    outputFluidOrItem.asArray().key('results'),
    inputFluidOrItem.asArray().key('ingredients'),
    intNumber.key('secondaryFluidResults').optional(0),
    intNumber.key('secondaryFluidInputs').optional(0),
    intNumber.key('processingTime').alwaysWrite().optional(40),
    heatCondition.key('heatRequirement').optional('none')
  )
)

The recipe JSON takes a secondary input as an index, and not even an index in the elements of ingredients or results

#

It's the index of the fluids in in both arrays, so if you have a mixed item/fluid input or output, your indexes are FUCKED

glacial yew
#

yeah I remember playing with this

hardy shore
#

Yeah... so what I did instead

#

my helper class just remembers what you want to instantiate, sets the index to 0 and prepends your secondary to the beginning of the ingredients

#

Can't fuck it up that way. I basically just don't want to specify an index EVER.

#

I just can't get completions on it if I don't instantiate it directly.

glacial yew
#

@hardy shore can you point exactly where you want completition? and what do you expect?

#

hover the variable so I can understand

hardy shore
#

When I invoke pressurizing

image.png
#

It should know that pressurizing is of type CVIPressurizingWrapper

#

but I don't get the completions for methods of CVIPressurizingWrapper

#

Not the end of the world, but slightly annoying because it means I have to open the definition back up.

glacial yew
#

how did you instantiate create

hardy shore
#

It's just an extra wrapper around all the other stuff. the variable is essentially this

/**
 * @param {Internal.RecipesEventJS}
 */
const defineCreateRecipes = (e) => {
  return {
 
    /**
     * @callback {CVIPressurizingWrapperCB}
     * @param {(InputItem_|Internal.InputFluid_)[]} inputs
     * @returns {CVIPressurizingWrapper}
     */
    /**
     * @type {CVIPressurizingWrapperCB}
     */
    pressurizing: getConstructorWrapper(e, CVIPressurizingWrapper),
  }
}
#

I do this once at the top of the recipes script and get aliases to all my create helper wrappers in the correct RecipeEventJS context.

# 
ServerEvents.recipes(e => {
  const create = defineCreateRecipes(e)
})
#

ok uh

#

I fixed it?

#

Apparently it needs to be:

/**
 * @callback CVIPressurizingWrapperCB
 * @param {(InputItem_|Internal.InputFluid_)[]} inputs
 * @returns {CVIPressurizingWrapper}
 */
/**
 * @type CVIPressurizingWrapperCB
 */
#

Note the lack of braces around @type and @callback

glacial yew
#

did it work? i'm reading stackoverflow and looks like you would do:
@type {CVIPressurizingWrapperCB:CVIPressurizingWrapper}

#

ops

#

@type {function(CVIPressurizingWrapperCB):CVIPressurizingWrapper}

hardy shore
#

the argument is inputitem or fluid, so it would b e
@type {function((InputItem_|Internal.InputFluid_)[]):CVIPressurizingWrapper} I think

#

let me try that

#

oh that works too

#

I like that more so I don't have to use @callback

#

The only problem is it goes over 80 lines

# 
/**
 * @type {function((InputItem_|Internal.InputFluid_)[])
 *   :CVIPressurizingWrapper}
 */

This also works though.

#

I wonder if I can still name the parameter as well.

glacial yew
#

👏

hardy shore
glacial yew
hardy shore
#

Aha

#

Very useful

#

Thank you very much

#

I was surfacing other stuff by searching jsdoc function arguments

glacial yew
hardy shore
#

oh it accepts arrow function syntax too

#

very cool

#

im going go fix all my jsdoc now

#

Woohoo! This fixed my custom SequencedAssembly wrapper too!

#

much appreciated ☕