WIP: y scrolling code block, select block added, debug filter block e… #3
Conversation
DivadNojnarg
added
documentation
|
@DivadNojnarg I'm sorry, I tried to fix some issues, but probably broke some of your work on select/plot blocks in doing so. One of the goals was to be able to specify "dependencies" between fields (and data). I am trying out something using quoted expressions which then can be evaluated in the context of data and other field values, e.g.: https://github.com/cynkra/blockr/blob/16837a030da3118a76820e30a9c8b8200cee9480/R/block.R#L177 Happy to discuss! |
|
@nbenn . I just merged your changes in this MR. Going to check the select and plot blocks. 
|
Codecov Report
@@ Coverage Diff @@
## main #3 +/- ##
==========================================
- Coverage 55.78% 54.17% -1.61%
==========================================
Files 7 7
Lines 294 371 +77
==========================================
+ Hits 164 201 +37
- Misses 130 170 +40
|
R/block.R
Outdated
| new_filter_block <- function(data, columns = colnames(data)[1L], | ||
| values = character(), ...) { | ||
|
|
||
| sub_fields <- function(data, columns) { |
There was a problem hiding this comment.
@nbenn : do we expect module developers to write this?
There was a problem hiding this comment.
It depends what the module author wants to achieve.
If you have static fields, it's as simple as
If you have a simple dependency on the data you can get away with something like
(where in the newest iteration, you'd do col_choices <- function(data) colnames(data) instead of cols <- quote(colnames(.(data))) but that's a minor detail)
Now if you want to enable arbitrary "functional" dependencies between fields, the logic for what kind of actions changes the block state in what way, then yes, this logic has to be represented somehow. Tbh, I personally don't find
to be that unwieldy. This simple specifies what kind of "sub fields" are added for what kind of columns. Something like this could even be offered as exported utility function (as long as the user is happy with our type-mapping decisions).
As for
I agree, this is a bit harder to appreciate. The problem I see here is tension between ending up with an "idiomatic" expression (like using infix `|`() vs. prefix between()) and compactly/readably expressing the underlying logic. Over time, we might be able to offer some utilities to make this easier. But for now I was more trying to explore what is possible and how something like that could be done.
|
The author of this PR, DivadNojnarg, is not an activated member of this organization on Codecov. |
Can't create DRAFT...