This commit standardizes the naming convention to be used for the UI
components being used in the `/devtools/` storybook-like pages for
testing the UI components.
This commit adds the redesigned banner component to the codebase along
with a storybook-style page in /devtools/banners to view and test the
redesigned banner component.
Any banner using the new redesigned styles, requires two classes,
- First, the base `banner` class which defines the structure and
behavior of the banner.
- Second, a modifier class like `banner-info` which defines the styles
for the particular banner type.
The navbar alert banners also have a custom class `navbar-alert-banner`
which is used to define the specific style and structure for these
banner types.
This commit also makes the `banner`, `action-button` and `icon-button`
components into handlebar templates to maintain consistency in their
usage in the codebase.
This includes bootstrap.portico.css and happens to prevent webpack
from kicking it out of the chunk with the rest of the portico CSS and
misordering it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit adds the redesigned button styles to the codebase along with
with a storybook-style page in `/devtools/buttons` to view and test the
redesigned button component.
The redesigned button component, uses the `action-button` class to
follow Zulip's no-abbreviation policy, and to avoid conflicts with the
pre-existing `button` and bootstrap `btn` classes.
A button using the new redesigned styles, required two classes,
- First, the base `action-button` class which defines the structure
and behavior of the button.
- Second, a modifier class like `action-button-primary-neutral` which
defines the styles for the particular action button type.
We now use micromodal in the modal on dev server emails page to
make it consistent with other modals in the app and this is
preparatory work for moving away from bootstrap as well.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
