diff --git a/client/layout/guided-tours/docs/ARCHITECTURE.md b/client/layout/guided-tours/docs/ARCHITECTURE.md index 0f451aa7ff7a8..f50b9573bf897 100644 --- a/client/layout/guided-tours/docs/ARCHITECTURE.md +++ b/client/layout/guided-tours/docs/ARCHITECTURE.md @@ -6,7 +6,7 @@ Guided Tours was built with a couple of premises in mind: notably, 1/ that it had to be flexible enough to accommodate all sorts of tours, launching them based on different triggers, and 2/ that we cannot yet know what these triggers will look like. That was the main factor that lead to to our approach, but it was corroborated by other requirements, such as testability and debuggability, minimizing state issues, etc. -Thus [`actionLog`][actionLog] was born. As the name suggests, it consists of a list of Redux actions, each with its own timestamp. These are actions that have been dispatched and whose action type can be found in a whitelist of "[relevant types]" — in other words, actions that Guided Tours is interested in for the triggering of tours and the transition of tour steps. By design, `state.ui.actionLog` is never persisted (meaning it starts as an empty list with new each Calypso session) and is limited to the latest 50 collected actions, pushing out older ones. +Thus [`actionLog`][actionLog] was born. As the name suggests, it consists of a list of Redux actions, each with its own timestamp. These are actions that have been dispatched and whose action type can be found in a specified list of "[relevant types]" — in other words, actions that Guided Tours is interested in for the triggering of tours and the transition of tour steps. By design, `state.ui.actionLog` is never persisted (meaning it starts as an empty list with new each Calypso session) and is limited to the latest 50 collected actions, pushing out older ones. With `actionLog`, any number of selectors can be written and composed to process the log and derive useful information. For instance, by collecting `ROUTE_SET` actions, and we can obtain the user's recent navigation history; by collecting `FETCH_FOOS_SUCCESS` we can have a tour transition to a new step only when a certain collection of data has been retrieved from the server. Hypothetically, more complex behavioral patterns can be inferred. Imagine the following: a user is entering a Calypso section, then another, then another, all of these in rapid succession, with other actions in between — can we infer that they are unsuccessfully looking for a specific feature? If so, we can offer help contextually. diff --git a/client/my-sites/marketing/connections/service-examples.jsx b/client/my-sites/marketing/connections/service-examples.jsx index 2a57dad31f271..4a2de734e9d14 100644 --- a/client/my-sites/marketing/connections/service-examples.jsx +++ b/client/my-sites/marketing/connections/service-examples.jsx @@ -20,14 +20,14 @@ import { localizeUrl } from 'lib/i18n-utils'; * Module constants */ /** - * Whitelist of services that we provide examples for. + * List of services that we provide examples for. * - * When adding examples for more services, please update the whitelist in addition to adding + * When adding examples for more services, please update the list in addition to adding * a method with the example's content. * * @type {string[]} */ -const SERVICES_WHITELIST = [ +const SERVICES_WITH_EXAMPLES = [ 'bandpage', 'facebook', 'google_plus', @@ -305,7 +305,7 @@ class SharingServiceExamples extends Component { } render() { - if ( ! includes( SERVICES_WHITELIST, this.props.service.ID ) ) { + if ( ! includes( SERVICES_WITH_EXAMPLES, this.props.service.ID ) ) { /** * TODO: Refactoring this line has to be tackled in a seperate diff. * Touching this changes services-group.jsx which changes service.jsx diff --git a/client/my-sites/marketing/connections/service-tip.jsx b/client/my-sites/marketing/connections/service-tip.jsx index aec9577267aeb..0adde0a6b3499 100644 --- a/client/my-sites/marketing/connections/service-tip.jsx +++ b/client/my-sites/marketing/connections/service-tip.jsx @@ -17,14 +17,14 @@ import { localizeUrl } from 'lib/i18n-utils'; * Module constants */ /** - * Whitelist of services that we provide tips for. + * List of services that we provide tips for. * - * When adding tips for more services, please update the whitelist in addition to adding + * When adding tips for more services, please update the list in addition to adding * a method with the tip's content. * * @type {string[]} */ -const SERVICES_WHITELIST = [ 'facebook', 'twitter', 'instagram', 'google_plus' ]; +const SERVICES_WITH_TIPS = [ 'facebook', 'twitter', 'instagram', 'google_plus' ]; class SharingServiceTip extends Component { static propTypes = { @@ -102,7 +102,7 @@ class SharingServiceTip extends Component { render() { const { service } = this.props; - if ( ! includes( SERVICES_WHITELIST, service.ID ) || 'google_plus' === service.ID ) { + if ( ! includes( SERVICES_WITH_TIPS, service.ID ) || 'google_plus' === service.ID ) { return
; } diff --git a/client/my-sites/themes/themes-magic-search-card/taxonomies-config.js b/client/my-sites/themes/themes-magic-search-card/taxonomies-config.js index 88c6f4fea5f28..6897bbc672857 100644 --- a/client/my-sites/themes/themes-magic-search-card/taxonomies-config.js +++ b/client/my-sites/themes/themes-magic-search-card/taxonomies-config.js @@ -7,7 +7,7 @@ import { get } from 'lodash'; /** * Taxonomies allowed in the search welcome suggestion card. */ -export const taxonomiesWelcomeWhitelist = [ 'column', 'feature', 'layout', 'subject', 'style' ]; +export const allowedSearchWelcomeTaxonomies = [ 'column', 'feature', 'layout', 'subject', 'style' ]; /** * Associates an icon to each taxonomy. diff --git a/client/my-sites/themes/themes-magic-search-card/welcome.jsx b/client/my-sites/themes/themes-magic-search-card/welcome.jsx index d33c8b7eaa8d0..82f5bee34c087 100644 --- a/client/my-sites/themes/themes-magic-search-card/welcome.jsx +++ b/client/my-sites/themes/themes-magic-search-card/welcome.jsx @@ -12,7 +12,7 @@ import Gridicon from 'components/gridicon'; * Internal dependencies */ import i18n from 'i18n-calypso'; -import { taxonomiesWelcomeWhitelist, taxonomyToGridicon } from './taxonomies-config.js'; +import { allowedSearchWelcomeTaxonomies, taxonomyToGridicon } from './taxonomies-config.js'; class MagicSearchWelcome extends React.Component { constructor( props ) { @@ -123,7 +123,7 @@ class MagicSearchWelcome extends React.Component { renderTaxonomies = () => { const { taxonomies } = this.props; - this.visibleTaxonomies = intersection( taxonomies, taxonomiesWelcomeWhitelist ); + this.visibleTaxonomies = intersection( taxonomies, allowedSearchWelcomeTaxonomies ); return this.visibleTaxonomies.map( ( taxonomy ) => this.renderToken( taxonomy ) ); }; diff --git a/config/README.md b/config/README.md index 5c29ac2df3f47..e3f5e86041997 100644 --- a/config/README.md +++ b/config/README.md @@ -3,7 +3,7 @@ Config This dir is used to store `.json` config files. At boot-up time, the server decides which config file to use based on the `NODE_ENV` environment variable. The default value is `"development"`. The entire configuration is available on the server-side and most keys are also exposed to the client. The config is sent to the client as part of the initial payload in `server/render/index.js` and `client/document/index.jsx`. -If it is necessary to access a `config` value on the client-side, add the property name to the `client.json` file, which is whitelist of config properties that will be exposed to the client. +If it is necessary to access a `config` value on the client-side, add the property name to the `client.json` file, which is list of specific config properties that will be exposed to the client. Server-side and client-side code can retrieve a config value by invoking the `config()` exported function with the desired key name: diff --git a/docs/isomorphic-routing.md b/docs/isomorphic-routing.md index 1488efe87ba0f..6a8a2789d6668 100644 --- a/docs/isomorphic-routing.md +++ b/docs/isomorphic-routing.md @@ -43,7 +43,7 @@ sections and a section that renders its entire component tree at once (a _single rendered_ section). For this reason, we have to unmount and re-render component trees when switching between these two types of sections. We do this in a `page()` handler in [`client/boot`](../client/boot/index.js). You'll have to locate that -handler and add your isomorphic section to the `singleTreeSections` whitelist array. +handler and add your isomorphic section to the `singleTreeSections` array of allowed sections. * Behind the scenes, we're using a [util](../server/isomorphic-routing/README.md) that adapts `page.js` style middleware to [Express](https://expressjs.com/en/guide/routing.html)', our server router's middleware signatures. We might want to switch to an isomorphic router in the future. diff --git a/packages/i18n-calypso/README.md b/packages/i18n-calypso/README.md index 0bf318d7abbf7..b9480e8a8a7a6 100644 --- a/packages/i18n-calypso/README.md +++ b/packages/i18n-calypso/README.md @@ -375,7 +375,7 @@ export default withRtl( Header ); ## Some Background -I18n accepts a language-specific locale json file that contains the whitelisted translation strings for your JS project, uses that data to instantiate a [Tannin](https://github.com/aduth/tannin) instance, and exposes a single `translate` method with sugared syntax for interacting with Tannin. +I18n accepts a language-specific locale json file that contains the list of allowed translation strings for your JS project, uses that data to instantiate a [Tannin](https://github.com/aduth/tannin) instance, and exposes a single `translate` method with sugared syntax for interacting with Tannin. ### Key Hashing