This commit fixes a bug where the the bootstrap.app.css was taking
precedence over the legacy_portico_styles_bundle.css, following the
changes in commit 847a7f8f9c.
While this commit fixes the issue by importing legacy_portico_bundle.ts
instead of trying to fix the order sequence of
legacy_portico_styles_bundle.css, similar to the approach in commits
ead2f2d254 and
c6dcfbc480, the actual cause of this bug
remains unknown at the time of the commit.
Since the portico and billing pages don't include app_variables.css,
and component specific CSS files, such as `buttons.css`, we defined the
necessary subset of these styles in a new CSS file `portico_modals.css`
to make the redesigned modals work correctly in these pages.
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>