Should we change the components management in JSON routes (and/or globally)

[taorepoara]

In JSON routes views, we can define listeners by specifying a JSON object corresponding to the next one anywhere in the tree:

{
    "type": "listener",
    "action": "...",
    "props": { ... }
  }

I think that it could be clearer and would avoid problems if we'd change the type property name to something specific.

[taorepoara]

This change could avoid problems in the future if we want to add other types even in JSON routes like the views.

[shiipou]

You want it to change all components ?
Or just for the jsonRoutes listeners ?

You think of allowing something like this ?

return {
    username: user.name,
    type: user.role,
    onUpdate: {
      "_type": "listener",
      action: "updateUser",
      props: {
        id: user.id
      }
    }
  };
}

[taorepoara]

I think it would be better to have it in both systems.

Yes, that's what already allowed (except for the _type).

[shiipou]

I think it would be better to have it in both systems.

I think too. We need to keep it consistent or people will be lost.

Yes, that's what already allowed (except for the _type).

The problem of this is that we can lost people. They cannot really understand why type is the only key that will be prepend by a character.

[taorepoara]

The problem of this is that we can lost people. They cannot really understand why type is the only key that will be prepend by a character

I think later we might have more. But for now it's just a reserved property that is handle by our system.

[shiipou]

Ok, then I think the _ is better, because the @ is already used to be replaced value by our system.
And the $ will force the user to escape it in some languages.

[jonas-martinez]

I don't see why we would need to change the type property to something else specifically for listeners. Can you explain ?

[taorepoara]

It's because in the JSON routes that accept any kind of JSON, the pattern of an object that have two string keys (with a value that can be defined by the user) type and action has a to big probability. Since the type property is the discriminant for the Lenra components (will be if we want to add more components in the JSON route two), we can just change the discriminant property to something that have less probability and explain in the documentation that it's a reserved property key.

[shiipou]

type and action has a to big probability

Maybe we can just see if there is type, try to validate the component, if not valid, then send it like this to the client and show warning logs in the devtool.
So we can use type in our apps, but if the component has a listener then we use it.

[Nesqwik]

Ok I understand the issue, but it seems strange to me that only the "_type" is prefixed. While it indeed can work this way, I would suggest adding this prefix on every lenra-related keywords to avoid confusion.

It makes it more consistent and it make it easy to see if key is lenra-specific or it is about my app.

{
   "_type": "listener",
   "_action": "foo",
   "_props": {
       "myKey": "bar",
   }
}

Note : The only downside i can see with the "_" is that it is already used for the "_id" in mongo, this could create confusion.

[taorepoara]

I agree for the Mongo _id confusion.

The idea was to change only the type property since it's our discriminating property. Maybe adding special char before the key is not the best solution. We can change the key to make it more explicit like lenraType.

@lenra-io/devs What do you think ?

[taorepoara]

We've discussed about this subject in order to define a final solution.

We've decide to use the _type as a reserved keyword just like Mongo does for the _id so we use the same logic and the type is the only discriminant.

[taorepoara]

We can't change our votes, but with @shiipou comments the _type seems to be the best solution.

[taorepoara]

I prefer the $type but the escaping is a real problem

[shiipou]

We can't change our votes, but with @shiipou comments the _type seems to be the best solution.

You can change your votes by clicking this :