amannn

Notes:

• The compiler looks for occurences of <NextIntlClientProvider messages="auto">
• For every occurence, the module graph is traversed (static imports as well as lazy references), looking for client entry points.
• The namespaces within client module graphs are collected (e.g. useTranslations('ns1'))
• The provider is replaced with something like <NextIntlClientProvider messages={pick(useMessages(), ['ns1', 'ns2'])} />
• <NextIntlClientProvider messages="auto"> must be rendered in a Server Component when messages="auto" is used
• The compiler doesn't traverse nested segments. This is important, as it will not pull messages from segments that might not render into parent layouts.

Open questions:

• When `` is used in a layout, do we auto detect sibling entry points (page, `not-found`, …) and traverse those too? Or should the provider be explicitly used in each file and we only follow module references? Consider that `error.tsx` must be a Client Componen

amannn

/**
 * Converts lodash imports to use named imports.
 *
 * E.g.:
 * ```
 * import noop from 'lodash/noop';
 * ```
 * ... to ...
 * ```
 * import { noop } from 'lodash';

amannn

/******/ (function () {
  // webpackBootstrap
  /******/ "use strict";
  /******/ var __webpack_modules__ = {
    /***/ /*! runtime requirements: __webpack_require__, module */
    /*! ModuleConcatenation bailout: Module is async */
    30:
      /*!***************************!*\\
      !*** ./topLevelAwait1.js ***!
      \\***************************/

amannn

/******/ (function () {
	// webpackBootstrap
	/******/ "use strict";
	/******/ var __webpack_modules__ = {
		/***/ /*! runtime requirements: __webpack_require__, module */
		/*! ModuleConcatenation bailout: Module is async */
		30:
			/*!***************************!*\\
      !*** ./topLevelAwait1.js ***!
      \\***************************/

amannn

{"version":1,"resource":"file:///Users/jan/Projects/webgears/coupon-frontend-react/packages/coupon-frontend-react-shared/src/components/HttpErrorMessage/HttpErrorMessage.module.scss","entries":[{"id":"eROs.scss","timestamp":1649315261522}]}

amannn

import React, {PropTypes} from 'react';
import cx from 'classnames';
import cs from './Text.scss';

/**
 * Material-UI doesn't expose the Material Design typography in the
 * current stable version, but the upcoming major version does so
 * (https://github.com/callemall/material-ui/blob/next/src/Text/Text.js).
 * As the upcoming relase is currently in alpha version, this
 * component is back-ported so its API can already be used.

amannn

Hi!

I'm writing here, as this probably doesn't fit within a tweet :).

I was working on a bigger redux app not too long ago, where I had a lot of entities with relationships in between. The "store layer" was mostly concerned with fetching data, storing them, providing ways to create/update/delete them via REST and in more sophisticated scenarios optimistic updates, cancelling duplicate requests when data was fetched just recently or currently being fetched and paginating through lists.

As there is usually no special logic in regards to the type of an entity, I was trying to put together an abstraction layer for the actions, the reducers and the selectors so that doesn't have to be repeated all the time.

For data from endpoints like /user (only 1 instance) or /books (a list) this has worked quite well, but it became somewhat complicated with nested entities that have relationships. My wrapper offered a configuration to specify what kind of entities are related in what way (either 1:1, 1:n or n:m; e.g. `

amannn

import styles from './styles.scss';

...

render() {
  return (
    <a className={styles.root}>
      <span className={styles.icon}>😀</span>
      {children}
    </a>   

amannn

/**
 * Import modules from other files.
 * 
 * This example assumes that Shape.js lies in the same directory as this file.
 */
import Shape from './Shape';

/**
 * Native classes which can inherit from other classes.
 */