I'm trying to create a kind of "form-bulder" with Compose, I've already done something similar with the old xml view system, and it was inspired by Django Forms.
The things involved were a container view which holds all the methods for processing forms data, and various fields object (spinners, text, checkbox...) to be instantiated in the container.

The main problem to me is the "functional" approach used in compose that forces to have various mutable states for every field, in my case I need at least states for:
retrieve field data
set field data (as in lot of cases, the standard "compose way" doesn't suit, like for spinners)
set field state (for example highlighting a required field)
and others depending on field type...
While this seems to be the compose way to do it, to me it seems just a lot of confusion and not reusable code.

I've come to a good solution (at least, it seems so...) with encapsulating composable function in classes to have an object approach in which the object holds everything needed to operate on the composable function, so in a form builder i can make something like fieldOne.collect() or fieldOne.getFilteredData(filterLambda). Plus all the goods coming from inheritance and generics...

What I'm trying to understand is if this solution can be considered a good one or not, searching on the internet, no one is doing something similar (as the docs says, composable are declared as top level functions) and I'm worried that there's something I've not learned yet that can lead to problems/bugs...

Does anyone has the knowdlege to give me some clarifications ?

P.S. I know the "composition over inheritance" principle, and I'm currently using it for like every other part of the app, but in this case I didn't find a proper way to use it...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.