A few questions/remarks

[etiennebacher]

Hello @JohnCoene, since you asked for feedback, I have a few questions about this package because its purpose is not very clear to me.

1. From the readme:

   This means inputs can only be created individually, one function call creates a single input, it's difficult to dynamically generate multiple inputs given their IDs must be unique.

Isn't this one of the usecases for modules? Being able to create inputs dynamically without worrying about namespace conflicts?

2. I don't have a lot of experience with Javascript so I don't know when one would like to observe a class and not an input in particular. Could you give an example (and perhaps add it in the readme)?

3. The example in the readme works fine in the browser but not in RStudio browser. There are no buttons and I can't click on them.

4. More of a sidenote: I'm not a native English speaker so maybe I'm missing something but from what I can see litter is synonymous to "garbage" or "waste", so I'm just wondering if this is an appropriate name for a package

I hope it helps and thanks for all the tools you provide

[JohnCoene]

Thanks for the feedback Etienne, it's much appreciated!

1. You are correct, but this still assumes I know at development time, how many inputs are going to be needed.

mod_input("x1")
mod_input("x2")

But what if I do know at development time how many are going to be needed? Worse, these are then dynamically added and removed by the user as they use the application.

It's something I've dealt with a lot recently, I just JavaScript which makes things infinitely easier but I was hoping to bring something such to shiny for users who do not know JavaScript.

For instance, I read data from a database and I want to allow the user to interact and edit said data. You could use {DT} and make the table editable of course but what if you cannot use {DT} or you want finer input control in the table, {DT}, to the best of my knowledge, easily allows text inputs but what if some of them should be select inputs or radio buttons?

With JavaScript that's relatively easy to solve. What you could do is just render the inputs as you want them to be (select, radio, etc.) having a "type" of input for each column, each with their class, then you can observe on those classes and process accordingly.

It's difficult to explain, I have an internal repo with an example of what I mean: I have added you the repository, feel to take a look and run it to see what I mean. I don't think one could reproduce said repo in pure shiny with ease, it's not undo-able but would make for spaghetti code.

2. Very much the reason above (and many others). The point is not to listen to an individual input, but rather a collection of inputs.

Imagine you render records from a data.frame in separate Bootstrap "cards," there is a delete button on the card to delete the record.

$('.delete-button-class').on('click', (e) => {
  $(e.currentTarget)
    .closest('.card')
    .remove();
});

One observer does it. Having to create individual ones and listen to them individually, coupled with the fact that you can never know how many records/cards you need to render is a nightmare without JavaScript (at least to me).

3. The RStudio IDE is actually a web browser, it's built on chromium but I'm afraid it's often out of date by quite a bit. Lit requires web components which I do not think are supported in the IDE.

4. You're correct, I did it on purpose though, I'm not sure it's a good idea either.

Thanks again!

[etiennebacher]

I see, the point is to apply the same behavior to a list of elements that you know are going to be identical (e.g cards as you said) without having to observe each element in shiny. It's much clearer, thanks for the explanation.

I'm very interested to see how this package will evolve