The `Provider` suffix reads as a dependency provider rather than as preview
data, and it collides with the real providers in the codebase — `StringProvider`,
`PickerProvider`, the login feature's `AccountProvider` — so the name says
nothing about which of the two a class is. `PreviewParam` says it.
195 classes are renamed, along with the 185 files named after them, the konsist
rule that enforces the convention, the presentation-class file templates and the
onboarding documentation.
This cannot be split. `Konsist.scopeFromProduction()` scans the whole project, so
flipping the assertion before every class has moved leaves the rule red, and a
rule that accepted either suffix during a transition would be exactly the kind of
compatibility layer this convention change is meant to remove.
Two judgement calls in the rule itself. The `name.endsWith("PreviewProvider")`
exclusion is dropped: its only job was to reject a redundant `Preview` before
`Provider`, and the new suffix already contains it; no class currently ends with
`PreviewProvider`, so removing it changes nothing today. And
`EditableAvatarViewUriProvider` is renamed rather than deleted from the exclusion
list even though no such class exists in this repository, since it presumably
comes from the modules overlaid for the enterprise build.
Nothing keyed off the old suffix: no snapshot filename contains a provider class
name, so no Paparazzi image changes, and the Kover variants match on `*Presenter`,
`*State` and `*ViewKt`, so coverage bounds are unaffected.
Document InvitePeopleState and each of its properties, InvitePeopleEvents,
InvitePeopleRenderer and the presenter factory.
The state properties now say what drives them, in particular that
createRoomFromDmAction covers the case of inviting a third person into an
existing direct message, and that the factory accepts a null room for that flow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Create a new room when inviting people to a DM
* Improve screenshot tests
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
* Add `InvitePeopleState.sendInvitesAction`
Keep track of the progress on sending invites with a new state property.
* Keep `RoomInviteMembersView` open until invites are sent
* Sync strings from localazy
* extend `ProgressDialog` to support custom content
For my current design, a simple text element is insufficient. I extend
`ProgressDialog` to give more flexibility over the content of the dialog.
* Show progress dialog while invites are being sent
* Add new ProgressDialog previews to the naming exceptions list
* Update screenshots
---------
Co-authored-by: ElementBot <android@element.io>
Co-authored-by: Jorge Martín <jorgem@element.io>
Benoit Marty
hayaksi1
Jorge Martin Espinosa
Richard van der Hoff
ganfra