change hashes type from any to Record<string, string>

[Terence625]

🤔 What's changed?

⚡️ What's your motivation?

🏷️ What kind of change is this?

• :bank: Refactoring/debt/DX (improvement to code design, tooling, documentation etc. without changing behaviour)
• :bug: Bug fix (non-breaking change which fixes a defect)
• :zap: New feature (non-breaking change which adds new behaviour)
• :boom: Breaking change (incompatible changes to the API)

♻️ Anything particular you want feedback on?

📋 Checklist:

• [x] I agree to respect and uphold the Cucumber Community Code of Conduct
• [ ] I've changed the behaviour of the code
  • [ ] I have added/updated tests to cover my changes.
• [ ] My change requires a change to the documentation.
  • [ ] I have updated the documentation accordingly.
• [ ] Users should know about my change
  • [ ] I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[coveralls]

Coverage: 98.566% (+0.04%) from 98.525% when pulling a1f109a32286fc542d9ffd7d55f3e672d010c727 on Terence625:add-datatable-generic-type into f59ea9f239d98d5b9fdc1abb71bb8378767c181c on cucumber:main.

[unional]

Should it styled as Array<Record<string, string>> instead of Record<string, string>[]? For complex type, IMO Array<T> is more readable than T[].

[Terence625]

@davidjgoss Thanks for reviewing it, I intended to add generic type for hashes() in DataTable like following:

export default class DataTable<T extends Record<string,string> = {}> {

  hashes(): T[] {
    const copy = this.raw()
    const keys = copy[0]
    const valuesArray = copy.slice(1)
    return valuesArray.map((values) => {
      const rowObject = {} as T
      keys.forEach((key, index) => (rowObject[key as keyof T] = values[index]))
      return rowObject
    })
  }
}

But it throws typescript error: 'string' is assignable to the constraint of type 'T[keyof T]', but 'T[keyof T]' could be instantiated with a different subtype of constraint 'string'.(2322). It seems to be some tricky typescript issue and seems over-engineered.

I'll just do type assertion in my code which will do the same trick:

//feature file
some step definition
inputValue | inputType
test1 | test2
test3 | test4

//step definition file
Then('some step definition', function(datatable: DataTable) {
   const data = datatable.hashes() as {
   inputValue: string,
   inputType: string
 }
)

[Terence625]

@unional I think they don't have any difference. I just see the original codebase is using [] for array type in other places, I just intended to keep them in the same style.

[aslakhellesoy]

Hi @Terence625,

Thanks for your making your first contribution to Cucumber, and welcome to the Cucumber committers team! You can now push directly to this repo and all other repos under the cucumber organization! 🍾

In return for this generous offer we hope you will:

• ✅ Continue to use branches and pull requests. When someone on the core team approves a pull request (yours or someone else's), you're welcome to merge it yourself.
• 💚 Commit to setting a good example by following and upholding our code of conduct in your interactions with other collaborators and users.
• 💬 Join the community Slack channel to meet the rest of the team and make yourself at home.
• ℹ️ Don't feel obliged to help, just do what you can if you have the time and the energy.
• 🙋 Ask if you need anything. We're looking for feedback about how to make the project more welcoming, so please tell us!

On behalf of the Cucumber core team, Aslak Hellesøy Creator of Cucumber

[davidjgoss]

@unional I think the array-simple flavour of this ESLint rule strikes a good balance, I'd approve a PR to turn that on.