Allowing a list of forms to be called by formUI

[fozy81]

Hi @daattali

This is very nice and works well in this use case. I forked it in https://github.com/fozy81/shinyforms and tried to add the ability to add a list of forms in a single call of formUI. Not entirely successfully! I'm struggling with the new way to handle id using 'NS' function. So for instance, if you had a pre-made form e.g. name + address form, email form, and favourite package form. You could chain them together in a list and create a single form out of multiple sub-forms. This could make managing forms easier and prevent need to re-write or duplicate effort.

This is the same approach, I've used with my package (in draft stage!): https://github.com/fozy81/rdatamill

Also i've saved the question/forms to a table as well as the answers in my package. Giving all the results/answers the same structure. For easier analysis later. Also easier to handle versioning of the forms. i.e. the questions/forms/validation rules may change over time - need a way to know what version of the form was used when the data was submitted. Anyway, my package is very badly coded and happy to support this shinyforms - if I can be useful and we can work out a way to handle the complexity of validation rules and version-ing of the forms.

This is maybe something to think about, I'll try helping with something more practical next - adding support for my input types.

[daattali]

Hi, thanks for reaching out. Looks like you've been working on your package for quite some time and have some very nice screenshots! It might be more advanced than mine at this point. Looks like we had some of the same ideas :+1: This package is obviously not ready for use, though it does do the basic things that I've always done with all my other forms.

Re: validation: I just added support for that an hour ago. It might not be perfect but I haven't had very much time thinking about it, but for now I like how it works.

validations = list(
  list(condition = "nchar(input$name) > 3", message = "Your name must have at least 3 characters"),
  ...
)

And if any of the conditions aren't met, you get error messages for each one.

Re: saving the questions/forms: yeah, I plan on doing that too somehow. I know the current way of making everything a huge list is not ideal. I want to convert it to YAML or JSON, and then it's easy to save and share it and reuse it. I probably wouldn't do it as a table , though again - I've only given it 5 minutes of thought so far.

I don't quite understand what you mean by list of forms though. You mean like how in my second example I have two different forms? What exactly would you want to do with them? Just have them one after the other? Or somehow "combine" them into one? Without understanding too much what you mean, it doesn't sound like something I want to support. I don't want to have "an email form" and a "package form" and put them together somehow. Sounds weird to me unless you can clarify how that makes sense

Also, yes, Shiny modules are a bit weird to work with. Takes a bit of practice to get used to them. But they're really awesome. Without modules, the code for this package and the ease of use for end users would not be as smooth. I'm not sure if you're using modules or not, but thanks to modules it's so so elegant to make forms the way they're done here.

Also, I haven't tried installing your package yet, but I fully support your idea of generating the form with Shiny. I'm quite a big Shiny fan so that was my first thought too :)

I have to go back to working on my thesis for a while so I'll probably not develop this much more in the next couple weeks

[fozy81]

Hi, well I'm happy to help.

I found some very early work on shiny forms - but can't now find who's blog post/git post it was - but they used a table to hold the forms/questions in. I used this idea in my package and then used your shinyjs and ideas for your blogs about controlling flow of forms/submitting data. So it's been a pet project to help get better at shiny and developing forms.

The overall driving force for me in terms of shiny forms, is that a R developer can easily define the whole data collection and analysis process. Often the data collection is outside of the data analyst hands or using different software. So this helps with reproducing the whole experiment.

I think shiny modules look great and having run into the namespace issues - this looks like it's less of an issue - just need to try it out.

In term of chaining forms together, it is definitely weird. It's probably a bad idea..keeping them separate is probably easier and keeps it straight forward.

I'll work on the other open issues while you are busy - and hopefully suggest some useful improvements. Good luck with thesis!

[fozy81]

I'll close...

[daattali]

The chaining thing might make sense if you show me an example of what you mean and a usecase of how/when that'd be useful

[fozy81]

The use case is chain various forms together so that there is only one submit button at the end. But the more I think about it, just submit each form individually is best.

If there are number of separate forms e.g. landscape survey, soil profile, bird survey - all to be surveyed at the same time/location, then it's easier to put them in separate tabs or tabpanel or clickable table and work through them individually.

Although pagination of long surveys crosses my mind, maybe another issue.

[daattali]

Different forms can have different parameters, I don't think it makes sense to put them together, I wouldn't want that ability. I've learned from Hadley to be very opinionated in my packages :p

That is indeed a separate issue from "pages", which is something I briefly though about. I think there's room for that feature in the future and I have an idea of how to implement it, but I don't want to add it in right away because it's going to add a bit of complexity, I'd rather tackle the more basic issues first. This also opens up the door to things like "conditional pages"/conditional questions (questions that depend on other questions), which adds a whole other layer of complexity... so for now stick to the basic use cases until the main components get nailed down perfectly

[fozy81]

That's fine, it's been good for me to have someone to discuss with. And awesomely right in being opinionated about your package. Best to nail a simple package which can be expanded or augmented with other packages. Just let me know if there's anything I can help with, I think a solid form package for R would be really neat.