Reduce reliance on internals and improve UI consistency #1635
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This PR adds new useful components to help us keep a stable API without being subject to Discord's changes. It also reduces our usage of internals where not needed. Overall it creates a good foundation to improve our UI consistency as well as general stability relative to Discord updates.
Issues & Limitations
Escape
currently has no effect on our modal stackRemovals
DiscordModules
The large list of
DiscordModules
was reduced down to a very minimal subset consisting only of what is actively being used in the codebase. In the future, this should be pared down even further to the point of removal. A list of known modules may be an addition for the future in the plugin api, but it should be fully contained in the API package and unused in the main codebase.DiscordClasses
This module was completely removed. There are now only a couple of spots in the entire codebase where any internal class names are even used to maintaining this large proxied object was unnecessary. The couple of components that need internal class names now get them directly through
WebpackModules
.ClassName
Since the main feature of this utility class was to make the internal class names easier to work with, and the use of internal class names has been essentially removed, the need for this disappeared and thus it was removed.
Changed
Markdown
Now all of our internal markdown handling is done consistently rather than links working in some places but not in others. This is done with a small wrapper around Discord's markdown components with a slightly adjusted parser that allows for things like markdown links.
Added
Components
This PR adds some useful base components that have parity with Discord but are wholly owned and styled by us.
Text
Flex
Button
As well as relevant modal components
ModalHeader
ModalContent
ModalFooter
ModalRoot
ModalStack
CloseButton
Backdrop
Including a couple modals
ConfirmationModal
ChangelogModal
Details
Buttons
This allows for styling consistent with Discord's across our entire codebase. (Note: it does not replace all existing buttons just yet). The main difference from Discord's buttons--aside from being wholly owned and styled by us--is that the brand/primary is BD blue rather than Discord blurple. Though blurple is still a potential option.
See preview below.
Discord_ssrMx0ycqt.mp4
Text
This again has parity with Discord's internal text element but is wholly owned and styled by us. This gives us (and potentially plugins) a stable API for creating text that does not risk being broken by Discord's changes.
See preview below.
Modals
This also creates completely custom modals and removes our reliance on a lot of internals. It also creates a partially wholly owned ModalStack. The only Discord component there is the transition group to allow for the animations to play on opening and closing of the modals. It otherwise emulates Discord's perfectly. The only exception to this are the plugin settings modals. These are still done using the internals of Discord because otherwise plugins using internal components for settings would not be able to render. There is probably a combination of internal contexts that would allow this to work with our stack but it is not known at this time, additionally it would defeat the purpose of moving away from their internals to then make our modals depend on their contexts.
See preview below.
Discord_Tk9UGjl6CV.mp4