Create a Poll Component

[dankgarlic1]

I am building poll feature for frappe/meet where we can launch polls in chat and participants can vote, I saw that we don't have a poll component in frappe UI, would really appreciate it if you guys can make one!

[barista-for-frappe]

Net-new component request — no Poll component exists today (grep -ri poll src/components is empty), and no prior open issue covers it.

• Labeled enhancement + ui. Would live under src/components/ with a docs page in the Frappe UI book.
• Scope worth defining before build: single- vs multi-select votes, live result tally, and whether vote state is local or wired through a resource.

cc maintainers for prioritization.

_{barista · claude-opus-4-8 · 8.8k in / 1.9k out · 579k cached · 44s · $0.421}

[dankgarlic1]

will this issue be picked anytime soon?

[vinaypokharkar]

I'd like to pick this up, but a Poll would be a net-new public component, and per spec/README.md specs are the top of the source-of-truth order — so it needs an API contract agreed before code. Proposing one below, plus the gating question.

The gating question: should this be a component at all?

P8 says split components rather than overload them, and a poll decomposes cleanly into things the library already has — a choice control, Progress for the tally, and a submit Button. A reasonable answer here is "compose it app-side, we won't ship a Poll." If that's the call, I'll close this out with a docs recipe instead, which is probably more useful to @dankgarlic1 than waiting.

If you do want it, here's the shape I'd propose.

Family and conformance. It's a value-holding selection control, so it joins the selection family and conforms to spec/selection.md: primary value on v-model (§1), options shaped from the shared item object (§5), and options as the top-level prop name (§12). It's an input control under P5, so it extends InputLabelingProps (label, description, error, required). Styling hooks via data-slot / data-state only, per P10.

interface PollProps extends InputLabelingProps {
  /** Choices. Shared item object: { label, value, disabled?, icon?, description? } */
  options: PollOption[]
  /** Allow more than one vote. */
  multiple?: boolean
  /** Vote tallies, keyed by option value. Absent = results not yet known. */
  results?: Record<string | number, number>
  /** When to reveal the tally. */
  showResults?: 'always' | 'after-vote' | 'never'
  /** Poll is closed; votes are frozen, results shown. */
  closed?: boolean
  disabled?: boolean
}
// v-model: string | number  (single)  |  (string | number)[]  (multiple)

Results render as Progress bars — reusing the existing component rather than a second bar implementation.

A note on the single-select path. Radio semantics are needed for single-vote, and there's no Radio component today (#751 proposes one, still open). Rather than block on it, I'd build directly on reka-ui's RadioGroup / CheckboxGroup primitives, which is the same approach Combobox / MultiSelect already take with reka. Happy to align with #751 instead if you'd rather.

Open questions for you:

1. Ship a Poll, or close in favour of an app-side recipe? (gating)
2. If shipped — one component with multiple, following MultiSelect precedent, or two components per P8?
3. Does Poll stay presentational (results passed in via results), or is it expected to own vote submission through a resource?
4. Would this need its own spec/poll.md, or does it fold into spec/selection.md?

Not writing any code until there's a direction. Given the v1 RC work in flight (#734, #690, #722), I'd also understand entirely if this is post-1.0 — just say so and I'll pick something else up.

[dankgarlic1]

@vinaypokharkar we have made a poll ui on meet app, You can use that also for reference. Its in the suite monorepo

[vinaypokharkar]

Thanks, took a look at Meet's poll. Good reference for the flow — question + 2-10 options, lock after voting, per-option bar with vote count and %.

Main thing I'd change for a shared component: Meet drives votes through an injected service and bakes the tally into each option, and the question is just an <h3>. A library version would want to be presentational instead — value on v-model, tallies passed in via a results prop, and a proper label (InputLabelingProps) so it works without the meeting backend.

One thing I noticed: Meet doesn't reuse Progress for the bars, it hand-rolls them. Was that on purpose or just quicker at the time?

And the main question is still open — do you actually want a shared Poll in frappe-ui, or just an app-side one that matches Meet? Happy to spec it out and open a PR if it's the former, just didn't want to write code before knowing the direction.

[BreadGenie]

Why would you use an LLM to converse with actual humans?

[vinaypokharkar]

Sorry for that I am kinda new and just want to get along so i took help of llm to like make the changes more clear