Closed timvink closed 1 year ago
Hi again Tim. Whilst I agree that hooks have their use-cases, for the vast majority of tables to be used in documentation, they will not be needing major pre-processing. The needed functionality would be to query a "database"/file and select/filter/sort. Having a separate hook for each table you will need is overkill - for me at least. The difference from page to page will be .query('x=="A"')
, .query('x=="B"')
, etc. However, I do think #45 will provide a better solution if you manage to implement that as it is more Markdownian (if we can coin that term). :-)
as it is more Markdownian (if we can coin that term). :-)
Haha, good one! I see what you mean, I agree #45 is a better fit, and easier to implement. I also don't want to implement the same functionality twice, so closing this one.
Being able to do something like:
Might simplify a setup considerably.
I'm not sure if it's a good design choice though. You could use a hook to preprocess tables also (see preprocessing tables using hooks), which is probably a better design pattern (because then you don't have any data logic inside your documentation code, it's just input/output).
If you read this & have a use-case for this, let me know!