You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Working on some custome extensions, I've noticed that Tables seem to be the only token with an odd use of it's tokens parameter. Instead of being an array of tokens, it's instead an object which then contains two token arrays (header and cells). This means we have an odd special case that we have to handle in walktokens for example, and becomes confusing when writing an extension.
I think it would make sense to reorder these properties to follow the format of other tokens to change
tokens = {
header : [ ],
cells : [ ]
}
into
header.tokens = [ ];
cells.tokens = [ ];
This better follows the convention of other similar tokens with "sub-tokens" (e.g. Lists contain list items, which then contain tokens, rather than the list having a tokens object containing all the items). Lists are also a weird special case, but we might as well handle both special cases in the same way, and enforce that at least in our implementation, tokens always means an array of tokens.
This wouldn't change functionality, but just provide consistency between tokens.
Changes the token signature of Tables so maybe we can squeeze into version 3.0?
The text was updated successfully, but these errors were encountered:
Working on some custome extensions, I've noticed that Tables seem to be the only token with an odd use of it's
tokens
parameter. Instead of being an array of tokens, it's instead an object which then contains two token arrays (header and cells). This means we have an odd special case that we have to handle in walktokens for example, and becomes confusing when writing an extension.I think it would make sense to reorder these properties to follow the format of other tokens to change
into
This better follows the convention of other similar tokens with "sub-tokens" (e.g. Lists contain list items, which then contain tokens, rather than the list having a tokens object containing all the items). Lists are also a weird special case, but we might as well handle both special cases in the same way, and enforce that at least in our implementation,
tokens
always means an array of tokens.This wouldn't change functionality, but just provide consistency between tokens.
Changes the token signature of Tables so maybe we can squeeze into version 3.0?
The text was updated successfully, but these errors were encountered: