Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce reliance on internals and improve UI consistency #1635

Merged
merged 7 commits into from
Aug 29, 2023
Merged

Conversation

rauenzi
Copy link
Member

@rauenzi rauenzi commented Jun 15, 2023

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

  • Pressing Escape currently has no effect on our modal stack
  • Using Discord components in our modal stack causes rendering issues
  • Not all of our internal UI has been updated to use the new base components from this PR
    • This has been left as a future to-do.
  • The base components have not been exposed for plugins as a components API design has not been finalized
  • Some internals are still used where it would be a large effort (or impossible) to entirely remove the dependency

Removals

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.

image

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

@rauenzi rauenzi requested a review from Strencher June 16, 2023 03:19
@rauenzi
Copy link
Member Author

rauenzi commented Jun 16, 2023

@Tropix126 Can you take a look from a design perspective if I've missed anything?

@rauenzi rauenzi merged commit 9f950c1 into development Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants