Defining dynamic but consistent types

[js-jslog]

The FooByUser object is a simple structure representing the amount of foo performed by each user, setting each property's key & value to the username & recorded foo respectively.

The collection of keys composing the object may vary between objects representing different periods. For example if new user3 records foo in April then the March and April objects will differ in keys : {user1: 100, user2: 3} vs {user1: 87, user2: 5, user3: 30 }.

From a code documentation perspective I want to define FooByUser as having a set of property keys of known origin & type (if such a word can be used), but which cannot be predetermined for each particular instance.

Could we have a syntax something like the following?

interface FooByUser {
  *<username>: Number
}
def username {
  desc:    "The username of a user",
  source: {type: "database", location: "users.id"} 
}

Where the <> demonstrate that that we are using a def rather than a static key and the * represents that there may be more than one of these keys.

[maiermic]

I would generate the type definition of FooByUser using a script in your build process.

[Mouvedia]

IMO we should reuse the ES6 computed property name syntax.

// let's assume Integer is defined

interface FooByUser {
  ['username' + Integer]: Number
}
// or using expression interpolation
interface FooByUser {
  [`username${Integer}`]: Number
}

Concerning desc and source it should be considered as another feature and—if it is still warranted—moved to a separate issue.

[js-jslog]

I'm aiming at getting a type definition which is non-specific about the number and name of keys at run time, so generation at build time will not work unfortunately.

I like the suggestion of using a computed property syntax for bringing this non-specificity to the name of the key. We would still need a way of expressing the potential multiplicity of the property definition if this is all seen as worthwhile.

I will raise a separate issue to discuss the benefits of the desc and source proposal.

[maiermic]

@js-jslog Is this type only meant for documentation (no static or runtime type checking)?

[js-jslog]

The motivation for this question comes from wanting documentation for these types. In an ideal world we would have a solution open to all the type checking benefits too. I appreciate that this might create challenges there though..

[koresar]

Taking my question from #105

My issue is about values. Reading #97 it looks like the syntax for values is defined.

{
  String: Number
}

// or in my case
{String: RegExp}

Correct me if I'm wrong.

[Mouvedia]

Let's list the prerequisites. A property name can be of 3 types:

• identifier name
• string literal
• numeric literal (coerced into a string)

A property key value is either an ECMAScript String value or a Symbol value.

Which means we only have 2 possible types for the key: Symbol and String.
Now let's cover the simplest case: all properties of the object have the same type for both the key and the value.

Object( String: RegExp )
// equivalent to
{ String: RegExp }

We should be able to reuse Object.
cf #99 (comment)

What's the most common use case? The key being a string.
Which means we should cater for it by having a syntax which defaults to that type without having to specify it explicitly.

What should it be? Once we have answered that question we will have a proper basis so that we will be able to provide a generic solution to cover the case that interests the OP.

[koresar]

Look like #99 (and #97) is awaiting for the #80 to be closed. I believe #80 is settled. Can we close #80 as done, or is there some work on hold there yet?

[Mouvedia]

@koresar trying to tackle everything at once is not my strategy.
cf #96 (comment)

If we could settle for micro enhancements backed by real use cases, that would be much preferable.
It's also easier for ppl to chime in without excessive prior knowledge; which is a good thing if we strive for accessibility.

@ericelliott might have a say on this though.