Skip to content

Latest commit

 

History

History
1444 lines (945 loc) · 84.8 KB

CHANGELOG.md

File metadata and controls

1444 lines (945 loc) · 84.8 KB
Raw

@commercetools-frontend/application-components

21.8.1

Patch Changes

21.8.0

Patch Changes

21.7.0

Patch Changes

21.6.0

Minor Changes

  • #2581 339abbca Thanks @emmenko! - Introducing the Stacking Layer System.

    Background

    Components such as modal pages, dialogs, etc. are rendered using a "modal" container. These containers are then rendered within a special container called portals-container.

    Up until now, rendering these components required to define things like zIndex or level props, to imperatively determine how the component will be visible. This was required as the modal containers are positioned absolute and finding the correct z-index value is important.

    However, it's the responsibility of the developer to "pick" the correct values which is error prone. In fact, choosing a wrong z-index results in the modal to not be visible and thus leading to UI bugs.

    A better and more reliable approach would be for the Custom Application to automatically determine the correct z-index values for every modal container rendered on the page.

    Stacking Layer System

    To solve this issue, a Custom Application now implements a Stacking Layer System to automatically determine and apply the correct z-index values for every modal container.

    Therefore, it is not necessary anymore to explicitly provide the zIndex and level props to the modal pages or dialog components. The following props have been deprecated: level and baseZIndex (modal pages).

    To remove the deprecated props you can run the codemod remove-deprecated-modal-level-props:

    $ npx @commercetools-frontend/codemod remove-deprecated-modal-level-props 'src/**/*.js'

    For backwards compatibility, the zIndex prop is still supported and, if defined, it will overwrite the z-index value using !important. Therefore we recommend to only define it if absolutely necessary, otherwise it's safe to remove it.

  • #2594 d20638ef Thanks @kark! - Adds three new layout components: <InfoDetailPage>, <FormDetailPage> and <CustomFormDetailPage>.

    These components are similar to the <InfoModalPage>, <FormModalPage> and <CustomFormModalPage> respectively but they are not rendered as modals.

    Usage

    The detail pages are supposed to be used as a direct child of one of the main pages. The layout of those pages can be recognized by the gray background header and the white content background. A back link in the header section of each of the pages is required.

    InfoDetailPage

    Info Detail pages are controlled components used to render a page with detailed data.

    import { useHistory } from 'react-router-dom';
import { InfoDetailPage } from '@commercetools-frontend/application-components';
import Text from '@commercetools-uikit/text';
const DetailPage = () => {
  const history = useHistory();
  return (
    <InfoDetailPage
      title="Detail page"
      onPreviousPathClick={() => history.push('/starting-page')}
      previousPathLabel="Go back"
    >
      <Text.Body>{'Lorem ipsum ...'}</Text.Body>
    </InfoDetailPage>
  );
};

    FormDetailPage

    Form Detail pages are controlled components used to render a form with predefined control elements (primary and secondary button).

    import { useHistory } from 'react-router-dom';
import { useFormik } from 'formik';
import TextField from '@commercetools-uikit/text-field';
import TextInput from '@commercetools-uikit/text-input';
import { FormDetailPage } from '@commercetools-frontend/application-components';

const AccountPage = () => {
  const history = useHistory();
  const formik = useFormik({
    initialValues: {
      email: '',
    },
    validate: (formikValues) => {
      if (TextInput.isEmpty(formikValues.email)) {
        return { email: { missing: true } };
      }
      return {};
    },
    onSubmit: async (formikValues) => {
      alert(`email: ${formikValues.email}`);
      // Do something async
    },
  });
  return (
    <FormDetailPage
      title="Manage your account"
      onPreviousPathClick={() => history.push('/starting-page')}
      isPrimaryButtonDisabled={formik.isSubmitting}
      onSecondaryButtonClick={formik.handleReset}
      onPrimaryButtonClick={formik.handleSubmit}
    >
      <TextField
        name="email"
        title="Email"
        isRequired={true}
        value={formik.values.email}
        errors={formik.errors.email}
        touched={formik.touched.email}
        onChange={formik.handleChange}
        onBlur={formik.handleBlur}
      />
    </FormDetailPage>
  );
};

    CustomFormDetailPage

    Custom Form Detail pages are a variation of the <FormDetailPage> that allow passing custom control elements via formControls. This is useful in case the detail page needs different control elements than the default ones (primary and secondary button).

    import { useHistory } from 'react-router-dom';
import { useFormik } from 'formik';
import TextField from '@commercetools-uikit/text-field';
import TextInput from '@commercetools-uikit/text-input';
import { CustomFormDetailPage } from '@commercetools-frontend/application-components';

const AccountPage = () => {
  const history = useHistory();
  const formik = useFormik({
    initialValues: {
      email: '',
    },
    validate: (formikValues) => {
      if (TextInput.isEmpty(formikValues.email)) {
        return { email: { missing: true } };
      }
      return {};
    },
    onSubmit: async (formikValues) => {
      alert(`email: ${formikValues.email}`);
      // Do something async
    },
  });
  return (
    <CustomFormDetailPage
      title="Manage your account"
      onPreviousPathClick={() => history.push('/starting-page')}
      formControls={
        <>
          <CustomFormDetailPage.FormSecondaryButton
            onClick={formik.handleReset}
          />
          <CustomFormDetailPage.FormPrimaryButton
            onClick={formik.handleSubmit}
          />
          <CustomFormDetailPage.FormDeleteButton onClick={handleDelete} />
        </>
      }
    >
      <TextField
        name="email"
        title="Email"
        isRequired={true}
        value={formik.values.email}
        errors={formik.errors.email}
        touched={formik.touched.email}
        onChange={formik.handleChange}
        onBlur={formik.handleBlur}
      />
    </CustomFormDetailPage>
  );
};

Patch Changes

21.5.1

Patch Changes

21.5.0

Patch Changes

  • #2586 2f58b2d6 Thanks @emmenko! - Fix type declarations for <PortalsContainer> as defaultProps and forwardRef do not work well together.

21.4.0

Minor Changes

Patch Changes

21.3.5

Patch Changes

  • #2554 8e170c65 Thanks @emmenko! - Fix offset calculation for modal pages when notifications are opened.

21.3.4

Patch Changes

21.3.3

Patch Changes

  • #2541 3853d77e Thanks @emmenko! - Fix layout issue with modal components when the underlying page has a scrolling position, causing the modal container position to "scroll" with the page position.

    The expected behavior is for the modal page to always be correctly positioned and visible, regardless of the scrolling position of the underlying page.

    To fix that, the <PortalsContainer> now uses position: fixed when a modal container opens.

    The component now accepts some props to allow consumers to adjust the layout accordingly. However, for Custom Applications everything is pre-configured, so there is no action required.

21.3.2

Patch Changes

  • #2536 6a2c4195 Thanks @CarlosCortizasCT! - Make the title prop optional for the components <TabularMainPage> and <TabularDetailPage>.

    A warning will be logged if neither the title or the customTitleRow props are provided.

21.3.0

Minor Changes

  • #2503 421cc68b Thanks @kark! - Add a new <TabHeader> component.

    This component should be used to render tab elements within the tabular components, for example <TabularModalPage>. A <TabHeader> is rendered as a link and it assumes the "tab content" is controlled and rendered using <Route> components.

    import {
  TabularModalPage,
  TabHeader,
} from '@commercetools-frontend/application-components';

<TabularModalPage
  tabControls={
    <>
      <TabHeader to="/tab-one" label="Tab One" />
      <TabHeader to="/tab-two" label="Tab Two" />
    </>
  }
  // ...
/>;

  • #2517 9511e378 Thanks @kark! - Add two new layout components: <TabularMainPage> and <TabularDetailPage>.

    These components are similar to the <TabularModalPage> but they are not rendered as a modal. However, the layout itself is very similar between all the tabular components.

    Tabs must be rendered using the <TabHeader> component via the tabControls prop. A <TabHeader> is rendered as a link and it assumes the "tab content" is controlled and rendered using <Route> components.

    Usage

    As the name implies, these components are meant to be used in different places.

    The <TabularMainPage> is supposed to be used in one of the main application landing pages, as the top level component page. From a hierarchy point of view, there should be no parent pages. The layout of this page can be recognized by the white background header and the gray content background.

    Example:

    import {
  TabularMainPage,
  TabHeader,
} from '@commercetools-frontend/application-components';

<TabularMainPage
  title="Main page"
  tabControls={
    <>
      <TabHeader to="/tab-one" label="Tab One" />
      <TabHeader to="/tab-two" label="Tab Two" />
    </>
  }
>
  <Switch>
    <Route path={`/tab-one`}>
      <Tab1 />
    </Route>
    <Route path={`/tab-two`}>
      <Tab2 />
    </Route>
  </Switch>
</TabularMainPage>;

    The <TabularDetailPage> is supposed to be used as a direct child of one of the main pages. Typically it's used as a detail page with multiple sub-pages (tabs). The layout of this page can be recognized by the gray background header and the white content background. A back link in the header section is also required.

    Example:

    import {
  TabularDetailPage,
  TabHeader,
} from '@commercetools-frontend/application-components';

<TabularDetailPage
  title="Detail page"
  onPreviousPathClick={() => history.push('/main')}
  previousPathLabel="Go back"
  tabControls={
    <>
      <TabHeader to="/detail/tab-one" label="Tab One" />
      <TabHeader to="/detail/tab-two" label="Tab Two" />
    </>
  }
>
  <Switch>
    <Route path={`/detail/tab-one`}>
      <Tab1 />
    </Route>
    <Route path={`/detail/tab-two`}>
      <Tab2 />
    </Route>
  </Switch>
</TabularDetailPage>;

Patch Changes

21.2.1

Patch Changes

21.2.0

Minor Changes

Patch Changes

21.1.0

Patch Changes

21.0.0

Patch Changes

21.0.0-rc.3

Patch Changes

21.0.0-rc.1

Patch Changes

21.0.0-rc.0

Patch Changes

20.13.0

Patch Changes

20.12.3

Patch Changes

20.12.1

Patch Changes

20.12.0

Patch Changes

20.11.0

Patch Changes

20.10.6

Patch Changes

20.10.5

Patch Changes

  • #2387 e897317a Thanks @fuchodeveloper! - The <*ModalPage> components now accept a prop afterOpenStyles to overwrite the default styles. You can pass a "class name" or a CSS-in-JS style object. This should be used only in cases the default styles are causing some layout issues.

20.10.4

Patch Changes

20.10.3

Patch Changes

20.10.1

Patch Changes

20.9.4

Patch Changes

20.9.3

Patch Changes

20.9.0

Patch Changes

20.8.0

Minor Changes

  • #2315 22177e58 Thanks @emmenko! - Expose <PortalsContainer> from @commercetools-frontend/application-components. In case you happen to use some of the modal components outside of a Custom Application, you need to additionally render the <PortalsContainer>.

    Moreover, to help managing modal components state (open/close), we now expose a state hook useModalState.

Patch Changes

  • #2313 9826a605 Thanks @emmenko! - Use new TS compiler options jsx: react-jsx and jsxImportSource: @emotion/react. All unused React imports then have been removed or migrated to destructured named imports.

20.7.0

Minor Changes

Patch Changes

20.6.0

Patch Changes

20.5.2

Patch Changes

20.5.1

Patch Changes

20.5.0

Patch Changes

20.4.0

Patch Changes

20.3.1

Patch Changes

20.3.0

Patch Changes

  • #2160 7734f69e Thanks @renovate! - Update dependency eslint-plugin-testing-library to v4 and use screen over assigning to rendered

20.2.1

Patch Changes

20.1.2

Patch Changes

20.0.1

Patch Changes

19.3.1

Patch Changes

19.1.0

Patch Changes

19.0.1

Patch Changes

19.0.0

Major Changes

  • #2041 a240f657 Thanks @emmenko! - - Requires a peer dependency of react@17, react-dom@17.
    • The @types/react* peer dependencies have been removed and included as normal dependencies with a minor range version.
    • The peer dependency react-intl now only requires version >=5.
    • The peer dependency @commercetools-frontend/ui-kit has been removed.

Patch Changes

18.7.0

Patch Changes

18.6.0

Patch Changes

18.5.6

Patch Changes

18.5.5

Patch Changes

18.5.4

Patch Changes

18.5.2

Patch Changes

18.5.1

Patch Changes

18.4.1

Patch Changes

18.4.0

Patch Changes

  • 63d9c424 #2049 Thanks @emmenko! - Bump uikit versions, use @manypkg/cli upgrade instead of bulk-update-versions.

18.3.0

Minor Changes

18.2.2

Patch Changes

18.1.5

Patch Changes

18.1.4

Patch Changes

18.1.0

Patch Changes

18.0.2

Patch Changes

17.10.2

Patch Changes

17.10.1

Patch Changes

17.10.0

Minor Changes

  • d86c2e8 #1934 Thanks @emmenko! - Introduce a new experimental opt-in feature to authenticate the application for local development, using an OIDC-like workflow.

    Disclaimer: this is an opt-in experimental feature. Use it at your own risk. We want to test this feature internally first. Until then, we discourage you to try it out.

    The feature can be enabled by setting the ENABLE_OIDC_FOR_DEVELOPMENT=true environment variable.

    In addition to that, we have a new package @commercetools-frontend/cypress, to include some useful commands for testing Custom Applications.

Patch Changes

17.9.1

Patch Changes

17.9.0

Patch Changes

17.8.0

Patch Changes

17.7.1

Patch Changes

17.7.0

Patch Changes

17.6.2

Patch Changes

17.6.0

Minor Changes

  • 81a274c #1897 Thanks @jonnybel! - Add support for the new horizontal constraint options from UI-Kit to the size prop of <ConfirmationDialog>, <FormDialog>, and <InfoDialog> components.

Patch Changes

17.5.0

Patch Changes

  • bf5f71e #1896 Thanks @emmenko! - Update docs-kit dependencies to v11, which supports emotion v11. As a result, the appkit bundles are using the correct emotion dependencies.

17.4.1

Patch Changes

17.3.1

Patch Changes

17.3.0

Patch Changes

17.2.1

Patch Changes

17.2.0

Patch Changes

17.1.1

Patch Changes

17.1.0

Patch Changes

17.0.1

Patch Changes

17.0.0

Patch Changes

16.18.0

Patch Changes

16.17.2

Patch Changes

16.17.0

Patch Changes

16.16.5

Patch Changes

16.16.4

Patch Changes

16.16.2

Patch Changes

16.16.1

Patch Changes

16.16.0

Minor Changes

  • 4216b92 #1685 Thanks @emmenko! - Refactor i18n package to consume compiled data from ui-kit translation messages. Furthermore, the @commercetools-frontend/i18n now exposes a compiled-data folder as well: @commercetools-frontend/i18n/compiled-data. This can be used the load pre-compiled messages and thus improving the runtime performance.

    Furthermore, the mc-scripts extract-intl command has been deprecated in favor of the more official message extraction with the @formatjs/cli: https://formatjs.io/docs/getting-started/message-extraction.

Patch Changes

16.15.9

Patch Changes

16.15.8

Patch Changes

16.15.3

Patch Changes

16.15.2

Patch Changes

16.15.0

Patch Changes

16.14.0

Minor Changes

  • 364e711 #1621 Thanks @renovate! - feat(deps: add support for react-intl v5 through peer dependencies fix(deps): update dependency react-intl to v5

Patch Changes

16.13.2

Patch Changes

16.13.0

Minor Changes

  • f70fed0 #1595 Thanks @Rombelirk! - refactor(application-components, visual-testing-app): migrate PageUnauthorized component to AppKit

16.12.0

Minor Changes

Patch Changes

16.10.0

Patch Changes

16.9.2

Patch Changes

16.9.1

Patch Changes

16.9.0

Minor Changes

Patch Changes

16.8.8

Patch Changes

16.8.6

Patch Changes

16.8.5

Patch Changes

16.8.4

Patch Changes

16.8.3

Patch Changes