Dev docs comments

[maelle]

I'll take notes here.

• Beside saying a block is a module it would make sense to also write a workflow is a Shiny app.

[maelle]

• the docs about creating a block should say that it needs to be wrapped in a package? (in the case in https://blockr.site/docs/dev/create-block.html#registering-your-block where would the code be stored for later? isn't creating a package what should be recommended?)

[maelle]

Somewhere in the docs it'd make sense to explain what blockr brings compared to building your own Shiny app (more built-in stuff)

[christophsax]

Addressed in #29

[christophsax]

Added "a workflow is a Shiny app" to the dev docs intro, and a note that blocks should live in an R package so they can be registered, shared, and tested.

[christophsax]

Part of this addresses the bigger question: Why blockr? Why not Shiny? Why not Power BI? blockr is something in between. Less code than Shiny, more R than Power BI.

We should address at some point.

[maelle]

This could be good content

• for the docs website
• for an intro blog post

[maelle]

And also how it's better than just telling an agent to build you a whole app (blockr is more validated)

[maelle]

When one writes a block does one need to re-write the docs of a function somehow? E.g. why isn't https://github.com/BristolMyersSquibb/blockr.dplyr/blob/6ca64776083f789a21f529716960d420614e127e/R/registry.R#L177 generated automatically? Or is it?

[maelle]

Can one use blockr to quickly prototype a Shiny app?

[maelle]

The docs should first state where you'd write a block. A package? A project?

[maelle]

to not forget: blockr + dm would be the ultimate use case (already in examples I suppose, but good to highlight once more).