[Beta] SuperDatePicker — free custom date slicer, would love feedback from fellow devs

[BIsuperhero]

Hi all,

I've been building a custom date slicer for Power BI over the past few months and I've just pushed it into public beta. Posting here because this board is where the people who'll find the rough edges actually hang out, and I'd value your feedback before I cut a 1.0.

It's called SuperDatePicker. Free, MIT-friendly dependencies, no telemetry, distributed as a .pbiviz (not on AppSource yet — more on that below).

What it is

A replacement for the built-in date slicer with three modes:

• Single date picker — input box opens a modal calendar
• Date range picker — modal with preset buttons (Today, Yesterday, This/Last Week, This/Last Month, custom day counts)
• Mini-calendar — inline, no modal, fits in a tile

Built on React 18 + react-day-picker 8.x, packaged with pbiviz 5.6, API version 5.11.0. Filtering goes through AdvancedFilter on a Date/DateTime category.

Things I tried to get right (and would love you to break):

• High-contrast mode across all 4 Windows presets. This was the part that took the longest. I ended up bypassing my own resolveColor() in HC because Power BI persists previous theme colors into settings and they get treated as user choices. I'd genuinely like someone to try it on Service with a stubborn HC palette and tell me where it breaks.
• Formatting model with 8 cards / 90+ properties built on powerbi-visuals-utils-formattingmodel. Currently mid-refactor to split calendarStyle into calendarHeader + calendarGrid for the next major.
• Config export/import as JSON through a strict whitelist schema with regex-validated colors and a 5000-char input cap. No eval, no Function, no network.
• Localization via ILocalizationManagerwith date-fns locales mapped from Power BI locale codes.
• Zero privileges declared in capabilities.json. No network, no storage, no eval. Should pass certification when I submit.

What's stable, what isn't

The filtering path (DateTime category → AdvancedFilter → bookmark restore) is solid and I'm using it on real reports. Beta is mostly about:

• Formatting-pane layout — I'm planning a breaking change to split cards before 1.0, so feedback on the current pane structure would help me get that right
• A handful of known-rough edges around dynamic dialog sizing
• Edge cases I haven't seen yet, which is why I'm here

Why not on AppSource yet

I want one more pass on the formatting pane (the breaking refactor) before I lock in a certified version. Once that lands, I'll submit. Backward compatibility for configs is guaranteed across the change.

What I'd especially like feedback on

1. HC mode in Power BI Service with non-default palettes — please try to break it
2. Formatting-pane ergonomics — anything that feels nested wrong or hard to find
3. Modal dialog UX — particularly on small tile sizes and dense reports
4. Anything you'd expect a date slicer to do that mine doesn't — I have a list (default selection, holidays, ...) but I'd rather hear what you'd reach for first

Try it

• Download (.pbiviz) and docs: superdatepicker.com
• Deployment repo: github.com/robertjunek/super-date-picker-code
• Issues / bug reports: GitHub issues, or reply here

Thanks for reading. Happy to answer anything about the implementation in the comments.

Robert

Date rangeMiniCalendar

[Juan-Power-bi]

This looks really well thought out — the HC mode deep-dive alone shows a level of care that most custom visuals skip entirely. A few thoughts from the dev perspective:
On HC mode: The issue you described with Power BI persisting previous theme colors into formatting settings is a real pain. One pattern I've seen work well is to check host.colorPalette.isHighContrast on every update and explicitly override all resolved colors rather than trusting the persisted values. You probably already do this, but worth confirming you're doing it in update() not just initialization.
On the formatting pane (calendarStyle split): Given you're planning the breaking refactor anyway, I'd suggest surfacing "today highlight", "selected range color", and "weekend color" as top-level controls in whichever card they land in — those are the three things report authors reach for first and always hate hunting through nested cards to find.
On the modal dialog UX: One thing the native slicer still doesn't handle well is the case where the visual is near the bottom/right edge of the canvas and the modal clips. Worth testing that edge case specifically in the Service at 75% zoom.
Feature I'd reach for first: A "relative date" mode (last N days where N is a fixed number or linked to a parameter/measure) — I know it's on your list, but it's the #1 reason people abandon the native date slicer. Even a basic "last 30/60/90 days" preset would cover a lot of ground.
The zero-privilege capabilities.json is a smart move for AppSource submission — that'll make certification much smoother. Good luck with the 1.0!

[BIsuperhero]

Thanks for the detailed feedback — really appreciate the dev perspective.

On HC mode: confirmed, I'm already checking `host.colorPalette.isHighContrast` in `update()` and forcing all color overrides explicitly. The persistence bug is nasty and doing it only at init definitely isn't enough — good call highlighting that.

On formatting pane: fair point — my own clients tend to have fairly standardized report styles so I never felt the friction myself, but I can absolutely see how report authors in more varied environments would hate hunting for those three controls. Makes sense to surface them prominently in the refactor.

Modal clipping: good catch — I haven't actually tested that edge case yet, adding it to the todo to verify the behavior specifically at 75% zoom near the canvas edges in the Service.

Relative date mode: this is actually nudging it higher in my roadmap than I originally planned. Current thinking is an "last N" input with a toggle between days (default), weeks, and months — weeks because a chunk of my clients report on a weekly cadence, and months felt like a minimal addition that covers enough future use cases to be worth including from the start.

Thanks again — this kind of directional feedback is exactly what's useful!