Add a version of table.Entry that allows dumping the entry parameters.#689
Conversation
eefb527 to
a0905ed
Compare
|
Thanks @fedepaol - this is in the right direction but now I'm realizing why we might actually want to use some magic. The current implementation is not symmetric with the existing implementation of So I think we actually want At that point one could argue that we don't need WDYT? |
a0905ed to
bce59f1
Compare
|
The new version is a bit more complex on code, but I do agree, it looks a bit cleaner on client site. |
|
This looks great, @fedepaol - I think all it needs now is to be documented (inline in the comments, but also on the If you're up for adding some documentation let me know. Otherwise, I'll pull this in and document it myself. |
Sure, I'll do! TBH, it was pretty late yesterday and I wasn't able to find the docs :P |
Sometimes, it's useful to have the parameters of a given table entry as part of the description of the It counterpart. To achieve that, we allow passing a function as the description parameter. In case a string is passed, the previous behaviour is preserved. In case of function, it is expected to return a string that will be used as the new description for the generated It.
bce59f1 to
345b3d4
Compare
|
@onsi done! Feel free to correct it. |
|
Looks great! I’ll merge these in when i get to my desk. |
|
Thanks! When do you expect this to be available as a tag? |
|
I expect in the next couple of days or so |
Sometimes, it's useful to have the parameters of a given table entry as part of the description of the It counterpart.
To achieve that, we add a new family of Entry constructor that accept a function instead of the description as a string.
That function needs to be implemented by the client of the library, and it's called with the list of arguments and returns a string that will be used as description of the given entry.
This was discussed in #688
I am not totally happy with the naming, but I guess keeping it short-ish has a value here.