So I know there was a session, I think that <@UEJC...

# compose

[codeslubber]

So I know there was a session, I think that @Leland Richardson [G] did at DevSummit about how Compose actually implements its Builders, is there a document? also, lemme cast a vote for an example that shows a builder (domain-specific) that fronts compose…

[Adam Powell]

a builder (domain-specific) that fronts compose

Not sure what you mean by this, can you elaborate?

[codeslubber]

So let’s say I was going to do something like a construction kit for making surveys, I want to make it a declarative DSL, that looks like Compose code, but is using my own functions for things like question types, etc.

[Adam Powell]

to build a UI for surveys using Compose but using a survey-specific UI DSL, or to use Compose under the hood to build some other (non-UI) survey data structure that changes reactively over time?

[codeslubber]

well I am already doing the first part, I am just thinking that ultimately the declarative idiom for the actual surveys makes a lot of sense, e.g. for nesting

[codeslubber]

so yeah I want to write code that looks like Compose code, but is using my Survey types, which are implemented using Compose types

[codeslubber]

which is what DSLs generally are right? a set of domain-specific, idiomatic constructions that then use the underlying framework to produce their outputs…

[Adam Powell]

so you want to have Compose maintain a different data structure for you that is not UI?

[codeslubber]

no I think the data will use Compose, @model already let’s you have your own types right?

[codeslubber]

maybe I should just try this myself

[codeslubber]

remember Anko? you are writing in a DSL that is then turning into HTML..

[Adam Powell]

well, android views rather than html in that example 🙂

[Adam Powell]

I'm trying to determine whether Compose would be overkill for the use case you're thinking of

[codeslubber]

not sure what you mean by that, I am pretty sure declarative is a great match for surveys

[codeslubber]

storyboards make zero sense, if I made a survey with 30 questions, I am not going to make storyboards for where all of them appear

[codeslubber]

especially when the view is a pairing of a prompt or question, with some input mechanism which you want to make consistent

[Adam Powell]

ok, so it is producing a UI for the survey then?

[Adam Powell]

I may be inferring way too wide of a generalization here since I've been poking around in the composer infrastructure lately 🙂

[codeslubber]

yeah I will show you something in a few days, I am mostly thinking that some of the things that make surveys inscrutable might be solvable with a DSL, which got me all excited..

[Adam Powell]

cool, I'd love to see it 🙂

[codeslubber]

even without access to NumberPicker and some of the other controls, Compose has been great for this so far!

[Adam Powell]

if I'm understanding you right, yes, you should be good to go creating some sort of surveys "design library" similar to how the material design library builds on the other compose UI constructs

[codeslubber]

exactly!

[Adam Powell]

oh, then in that case, yes of course, that sort of thing is the intended use case for compose in general :)

[Adam Powell]

(and I'm glad to hear you're enjoying it; I've spent my morning here beating my head against what suspending code our kotlinc IR snapshot in -dev04 will or won't compile correctly for a hobby app...)

[codeslubber]

thanks for the efforts, yeah it is going in the right direction!