Los sitios web de noticias de BBC World Service se representan utilizando Simorgh, una aplicación basada en Reactjs. Simorgh también ofrece páginas de artículos de noticias de AMP para el servicio mundial, noticias de servicio público y deporte de la BBC.
Simorgh ofrece una experiencia web rápida y accesible utilizada por millones de personas en todo el mundo cada mes (consulte la lista de sitios web que usan Simorgh). Se mantiene regularmente y se documenta bien, y damos la bienvenida a los contribuyentes de código abierto.
Simorgh es mantenido principalmente por los equipos de ingeniería web de BBC News. Ofrece noticias muy confiables a los lectores de todo el mundo, actualmente en (41 idiomas). Apoyamos una amplia gama de dispositivos y cuidado profundamente sobre la escala, el rendimiento y la accesibilidad. Trabajamos en equipos ágiles y flexibles, y tenemos una hoja de ruta emocionante para el desarrollo futuro.
Familiarícese con nuestro:
NB hay una documentación adicional colocada con código relevante. La lista anterior es un índice de la documentación de nivel superior de nuestro repositorio.
Se transmite una solicitud a un artículo de la BBC (https://www.bbc.co.uk/news/articles/clldg965yzjo) a la aplicación Simorgh de un servicio de enrutamiento y almacenamiento de almacenamiento patentado (llamado Mozart).
La solicitud coincide con una ruta en nuestro servidor Express utilizando un Regex Match ( articleRegexPath || frontPageRegexPath ). Si la URL coincide con el patrón regex predefinido para un artículo o una página principal, obtenemos algunos parámetros de la ruta utilizando la función getRouteProps . Esto devuelve las propiedades de servicio, ISAMP, ruta y coincidencia. La ruta es una ruta React-Router que define un método para obtener el JSON inicial utilizado para representar la página y el contenedor React en el que representa IE ArticleContainer , esto generalmente se llama getInitialData
Una vez que se devuelven los datos, extraemos el código de estado y pasamos todos estos datos como accesorios para nuestro documento principal utilizando renderDocument .
El documento pasa la URL, los datos JSON, el origen de la BBC, el ISAMP y el servicio al contenedor de la aplicación principal y el resultado se representa a una cadena utilizando el método renderToString reaccionado. Esta cadena se pasa a documentComponent como la aplicación principal junto con la matriz de activos, las etiquetas de estilo (la salida de los componentes de estilo) y cualquier scripts/enlaces que necesiten agregarse al cabezal. Luego se renderiza al marcado HTML estático usando reacciona renderToStaticMarkup y se envía de regreso al usuario como HTML estático. En esta respuesta se incluyen enlaces a nuestros paquetes JS que un dispositivo de usuarios descargará para arrancar la aplicación de una sola página (SPA) para viajes posteriores.
Ahora que se ha descargado el HTML sin procesar, el archivo JS del lado del cliente entra e hidrata la respuesta inicial con la aplicación del lado del cliente. Durante este proceso, React utiliza la carga útil JSON inicial (disponible en el objeto de ventana global SIMORGH_DATA ) para hidratar el marcado original devuelto por ReactDomServer. React espera que el contenido renderizado sea idéntico entre el servidor y el cliente (es por eso que enviamos la carga útil JSON inicial con la página SSR, por lo que la fase de hidratación se ejecuta con los mismos datos que el servidor renderizó).
La carga útil JSON para un artículo consiste en una serie de bloques. Cada bloque es un objeto que representa un elemento en la página, este podría ser un encabezado, una imagen, un párrafo, etc. Cada uno de estos bloques tiene un tipo de bloque y un tipo de bloque coincidirá con un contenedor específico en Simorgh, por ejemplo, blocktype: la imagen coincidirá con el contenedor de imagen.
El contenedor Articlemain iterará sobre cada bloque JSON, lo coincidirá con su contenedor React correspondiente y pasará los datos a través de accesorios. Estos contenedores son donde se encuentra la lógica para representar cada tipo de bloque. Es en este punto donde usamos los componentes frontend instalados de la biblioteca de componentes PSAMMEAD. Por ejemplo, el contenedor de imagen importará el contenedor de figuras, y la figura importará y usará la imagen PSAMMead y los componentes Psammead-Image-Placeholder. Una imagen en un artículo generalmente tendrá un título, por lo que el contenedor de figuras importará el contenedor de subtítulos que puede incluir más componentes frontend de Psammead para representar un subtítulo en la parte superior de la imagen.
Este proceso se repite para cada bloque dentro de un artículo, lo que finalmente representa el cuerpo principal de un artículo de noticias utilizando una combinación de contenedores React para la lógica comercial y los componentes React para el marcado frontend.
Cada render se pasa a través de un conjunto de hoc (componentes de orden superior) para mejorar la página, estos hoc son;
Con una selección de tipos de páginas pasadas con OptimizelyProvider, que permite el uso de Optimizely en los tipos de página seleccionados.
La variante HOC asegura que los servicios que tengan variantes (por ejemplo, simp , lat ) siempre redirigen a una URL que hace la variante apropiada.
Si un usuario navega a una URL sin proporcionar la variante, y la variante se establece en Cookie, se representa la página de variante de cookies. De lo contrario, se representa la página de variante predeterminada
Si un usuario navega a una URL con una variante, y se establece una variante en Cookie, se representa la página de variante de cookies. De lo contrario, se representa la página de variante solicitada.
WithContexts HOC es un envoltorio que proporciona acceso a los diferentes proveedores de contexto disponibles en la aplicación. Cualquier componente infantil dentro de estos proveedores de contexto tiene acceso a los datos de contexto a través del gancho USEContexts.
El envoltorio hoc de la página simplemente envuelve el artículo o los contenedores de página principal con un diseño, en la actualidad solo tenemos un diseño de página única. Este diseño incluye los proveedores de encabezado, pie de página y contexto, lo que hace que el cuerpo principal como niño entre el encabezado y el pie de página.
El error HOC verifica el accesorio de error que se pasa, si el error se establece para anular, el artículo o el contenedor de página frontal simplemente se devuelve.
Si se establece un error en True, se devuelve el componente de error, dando al usuario una indicación visual del error, por ejemplo, una página de error 500.
Suponiendo que los otros hoc han devuelto el artículo original o el contenedor de página principal, los datos hoc ejecutarán algunas verificaciones de validación en los datos JSON pasados a través del accesorio de datos. Si se satisfacen todos los cheques, el ArticleContainer será devuelto con un solo accesorio pageData . Estos accesorios de Pagedata albergarán los datos JSON que se presentarán, por ejemplo, los bloques Optimo para un artículo determinado.
El WithhashchangeHandler Hoc es un envoltorio aplicado a todas las páginas que verifica los cambios en el valor del hash URL. Las páginas incluyen controles de accesibilidad para omitir el contenido si el usuario elige hacerlo, esto utiliza el hash URL para omitir a los usuarios a áreas específicas de la página. Debido a la naturaleza del enrutamiento del lado del cliente, los cambios en la URL resultan en un reiniciado. Esto causa algunos parpadeos de UI antiestéticos para algunos componentes, específicamente las incrustaciones de los medios y los medios sociales. Este hoc aplica verificaciones a la URL, así que vea si es necesario un re-renderizado o si no evita un re-renderizando usando React.memo .
WithOptimizelyProvider HOC devuelve componentes que se han mejorado con el acceso a un cliente optimizado, que se utiliza para ejecutar nuestras pruebas A/B. Esto se hace para limitar los tamaños de paquete, ya que separamos algunos de nuestros paquetes por tipo de página, eso significa que si solo estamos ejecutando pruebas A/B en ciertos tipos de páginas, podemos evitar que contaminantes paquetes de página con el peso de la biblioteca SDK que usamos para Optimizely.
WithOptimizelyProvider debe agregarse como el valor de la clave de objeto handlerBeforeContexts dentro de ApplyBasicPageHandlers.js, ya que el ckns_mvt se establece dentro del Usercontext, por lo que debe aplicarse con withOptimizelyProvider HOC en el orden correcto junto con los contextos hoc. Esto hace que el ckns_mvt esté disponible en las visitas por primera vez para pasar al OptimizelyProvider , junto con atributos como service , que se utiliza para determinar cuándo Optimizely debe habilitar un experimento.
Ejemplo para la página del artículo:
import withOptimizelyProvider from '#app/legacy/containers/PageHandlers/withOptimizelyProvider' ;
import ArticlePage from './ArticlePage' ;
import applyBasicPageHandlers from '../utils/applyBasicPageHandlers' ;
export default applyBasicPageHandlers ( ArticlePage , {
handlerBeforeContexts : withOptimizelyProvider ,
} ) ;Al agregar un nuevo tipo de página, se requieren varias piezas.
/data/{{service}}/{{pageType}}/.jsonlocalhost:7080/igbo.json debe tener los datos para construir la página de índice localhost:7080/igbomain con un flex-grow: 1; Declaración de CSS, esto es para asegurarse de que crezca para llenar el espacio entre el encabezado visual y el pie de página, la raíz Div utilizando una implementación de Flexbox 'Piefer'. cypress/support/config/settings.js para cada servicio (incluso si se establece el tipo de página nuevo en indefinido)cypress/integration/pages/cypress/integration/pages/ debe asegurarse de que las tuberías E2E se actualicen para ejecutar la nueva Tipeline E2E E2E y la tubería E2E Live E2ENB: Con tantos pasos, se sugiere tener múltiples PR al agregar un nuevo tipo de página para no tener un PR enorme singular. Sin embargo, si las pruebas de ciprés (#6) no se agregan en el mismo PR que el enrutamiento de la página (#5), deben seguir inmediatamente el enrutamiento de la página PR, idealmente estos deben manejarse en un solo PR.
Lea: contribuyendo.md
Instalar nodo. https://nodejs.org/en/. Utilizamos la versión especificada en .nvmrc y si tiene un administrador de versiones de nodo (NVM), puede ejecutar el siguiente script para cambiar automáticamente a la versión compatible con el proyecto.
nvm use
El proyecto Simorgh utiliza hilo para la gestión de paquetes. Se recomienda instalar el hilo a través del NPM Package Manager, que viene incluido con Node.js cuando lo instala en su sistema. Para instalar hilo, ejecute este comando:
npm install --global yarn
Luego puede ejecutar los siguientes comandos para instalar Simorgh
git clone [email protected]:bbc/simorgh.git
cd simorgh
yarn install
Para ejecutar esta aplicación localmente, con recarga de calor, ejecutar
yarn dev
La aplicación comenzará en http: // localhost: 7080.
Las páginas del artículo se sirven en rutas del formato /news/articles/:id donde la identificación es la ID de activo generada por el sistema de gestión de contenido.
FYI: Artículo que explica el uso de ID de la BBC en URL
Estos dos artículos de noticias están disponibles en el entorno de prueba de nuestro CMS, así como localmente, por lo que a menudo se usan para las pruebas:
También estamos sirviendo páginas AMP HTML en la ruta /news/articles/:id.amp https://www.ampproject.org
No se puede acceder a los servicios con variantes utilizando el formato anterior, en su lugar, la variante debe proporcionarse en la URL.
Las páginas delanteras del servicio mundial se atienden en el formato /:service donde service representa un sitio de servicio mundial:
Las páginas de primera línea del servicio mundial siguen el formato del artículo para AMP también, estar disponible en /:service.amp :
No se puede acceder a los servicios con variantes utilizando el formato anterior, en su lugar, la variante debe proporcionarse en la URL.
Las páginas de temas utilizan API internas de BBC a las que no son accesibles públicamente. Esto puede hacer que aparezcan las siguientes advertencias al desarrollar localmente:
No BFF_PATH set as environment variable, you will not have access to topics
Los desarrolladores internos que necesitan trabajar en páginas de temas localmente deben comunicarse con el equipo para obtener acceso.
Las recomendaciones en las páginas de cuentos también utilizan las API internas de BBC Data Labs. Requiere agregar el par de clave/valor en el archivo envConfig/secret.env para que aparezcan localmente.
Los desarrolladores internos que necesitan trabajar en las páginas de artículos localmente deben comunicarse con el equipo para el acceso.
Puede encontrar otros tipos de páginas mirando a través de nuestras rutas y sus asociados regular, pero le sugerimos que comience con lo anterior y luego eche un vistazo al núcleo de la aplicación para comprender y encontrar las otras rutas.
Utilizamos el libro de cuentos para desarrollar componentes de forma aislada de la aplicación Simorgh. Puede acceder a esto en https://bbc.github.io/simorgh/
Para ejecutar yarn storybook local, estará disponible en http: // localhost: 9001/. Introducción y documentación para el libro de cuentos está aquí: https://storybook.js.org/basics/introduction/.
Al ver historias de video localmente, asegúrese de usar un dominio BBC, como se describe en la sección Cambiar de ubicación de solicitud. El video no funcionará en la versión alojada de Storybook vinculada anteriormente por este motivo.
También usamos QA cromático para ejecutar pruebas de navegador cruzado en nuestras historias.
Tenga en cuenta también que si desea ver los componentes renderizados con nuestras fuentes, deberá forzar un repinte del lienzo. Esto se debe a que todas nuestras fuentes tienen la propiedad font-display de optional o swap de acuerdo con las estrategias de carga respectivas aquí: https://ws-dowloads.files.bbci.co.uk/fonts/index.html. La forma más fácil de forzar un repintado es solo mover el divisor entre la ventana de vista previa en la sección y Knobs o cambiar el tamaño de la ventana del navegador.
Si desea alojar la aplicación para que sea accesible a través de su red local, siga las instrucciones aquí.
Para ejecutar esta aplicación localmente con una compilación de producción, ejecute: yarn build && yarn start .
Utilizamos yarn build localmente que agrupa la aplicación que apunta a Localhost para obtener datos y activos estáticos.
Esto se usa principalmente para depurar latest utilizando los paquetes de prueba y entorno en vivo. Asegúrese de que los paquetes existan en la ubicación del activo estático para el entorno correcto antes de comenzar a depurar.
Para ejecutar paquetes de prueba en localhost:
envConfig/test.env cambia los valores de:LOG_DIR='/var/log/simorgh' a LOG_DIR='log'rm -rf build && yarn build:test && yarn startPara ejecutar paquetes en vivo en localhost:
envConfig/live.env cambia los valores de:LOG_DIR='/var/log/simorgh' a LOG_DIR='log'rm -rf build && yarn build:live && yarn startAlgunas características funcionan de manera diferente dependiente de si un usuario se encuentra dentro del Reino Unido o internacionalmente. Puede solicitar explícitamente una versión específica accediendo a Simorgh a través de un dominio BBC local de localhost específico:
Si estas URL no funcionan, es posible que deba agregar una entrada de archivo de hosts ( /etc/hosts o C:WindowsSystem32driversetchosts ):
127.0.0.1 localhost.bbc.co.uk
127.0.0.1 localhost.bbc.com
En el despliegue, make buildCi se ejecuta en el entorno CI que crea paquetes tanto para los entornos test como para los entornos live . En los dos entornos, los archivos .env.test o .env.live sobrescriben el archivo .env que se utiliza para ejecutar la aplicación con los paquetes correctos.
Cada ejecución de yarn build actualizará los archivos de análisis del paquete en el repositorio. Para ver un desglose del tamaño del paquete, abra el informe HTML generado en un navegador ./reports/webpackBundleReport.html Esto se genera a través de webpack-bundle-analyzer . Los datos también están disponibles como json ./reports/webpackBundleReport.json .
Tenemos pelusas con la guía de estilo Airbnb y usamos Prettier como un formato de código. Se pueden ejecutar con yarn test:lint .
Tenemos pruebas unitarias de Jest que se pueden ejecutar con yarn test:unit .
yarn test ejecuta ambos conjuntos de estos.
Usamos Cypress para nuestras pruebas de extremo a extremo. Para ejecutar las pruebas de humo localmente, ejecute este comando único:
yarn test:e2e
Girará un servidor de producción en el puerto 7080 y ejecutará las pruebas de Cypress contra eso. Para ejecutar las pruebas de humo de manera interactiva, ejecute:
yarn test:e2e:interactive
Esto carga una interfaz de usuario que permite ejecutar fácilmente las pruebas individuales junto con una secuencia visual del navegador, a medida que se ejecutan las pruebas.
Hay varias variables de entorno que puede usar con nuestra suite de prueba, que son:
| Variable de entorno | Efecto | Valores posibles |
|---|---|---|
| Cypress_only_service | Restringe a ejecutar solo el servicio especificado | Un solo servicio, es decir, CYPRESS_ONLY_SERVICE=urdu |
| Cypress_app_env | Ejecuta las pruebas en un entorno específico | test , local , live |
| Cipress_smoke | Ejecuta solo pruebas de humo si es cierto | true , false |
| Cipress_uk | Ver E2ES Running en el Reino Unido contra Live | true , false |
| Cypress_skip_eu | Ver E2ES fuera de la UE | true , false |
Estos comandos se pueden ejecutar en combinación.
La forma predeterminada de ejecutar la yarn test:e2e o yarn test:e2e:interactive ejecuta un subconjunto de nuestras pruebas, de lo contrario conoce como pruebas de humo . Para ejecutar la suite completa:
CYPRESS_SMOKE=false yarn test:e2e
Las pruebas se pueden restringir solo para ejecutarse para un solo servicio especificando con la variable de entorno CYPRESS_ONLY_SERVICE . Por ejemplo:
CYPRESS_ONLY_SERVICE=urdu yarn test:e2e
Para ejecutar solo una especificación particular, es necesario invocar ciprés directamente. Primero, asegúrese de que Simorgh ya se esté ejecutando en otra pestaña y luego se ejecute (por ejemplo, para ejecutar solo pruebas de artículo):
npx cypress run --spec cypress/integration/pages/articles/index.js
Se pueden encontrar más detalles sobre el uso de Cypress CLI en https://docs.cress.io/guides/guides/command-line.html
Esto afecta a los desarrolladores con sede en el Reino Unido (pero puede afectarlo si está utilizando una enrutamiento de VPN a través del Reino Unido)
La función Cypress .Visit () está bloqueada para visitar un solo dominio por prueba. Esto se vuelve problemático cuando lanza las pruebas E2E desde el Reino Unido, debido a las redireccionamientos de .com a .co.uk . Por defecto, las pruebas de Cypress se ejecutarán como si se ejecutaran fuera del Reino Unido. Para ejecutar estas pruebas desde el Reino Unido, debe pasar en la variable de entorno Cypress UK a las pruebas. Esto reemplazará las terminaciones de URL a .co.uk , lo que le permitirá ejecutar estas pruebas con éxito.
Aquí hay un comando de ejemplo:
CYPRESS_APP_ENV=test CYPRESS_UK=true CYPRESS_SMOKE=true yarn cypress
Esto afecta a los desarrolladores con sede en la UE (pero puede afectarlo si está utilizando un enrutamiento de VPN a través de un país que no está en la UE)
Ejecutar pruebas de cipreses fuera de la UE no mostrará los pancartas de consentimiento de la UE en AMP, y esto puede hacer que algunas pruebas falle. Establezca CYPRESS_SKIP_EU=true para evitar que estas pruebas se ejecuten cuando fuera de la UE.
Un comando de ejemplo será:
CYPRESS_SKIP_EU=true yarn cypress:interactive
El siguiente comando ejecuta Simorgh y Cypress:
CYPRESS_APP_ENV=local CYPRESS_UK=true CYPRESS_SMOKE=true yarn test:e2e
Cypress_app_env también se puede establecer igual a 'Test' y 'Live'. Cypress_smoke puede ser verdadero o falso. Es cierto de forma predeterminada y ejecuta un subconjunto específico de pruebas.
Utilizamos Lighthouse para probar el rendimiento de nuestra página. Sin embargo, estos se han trasladado de Simorgh a nuestros propios procesos internos de CD. Esto nos permite ejecutar estas pruebas en una representación más precisa de Simorgh. Usted es libre de ejecutar el faro por su cuenta desde su navegador Chrome o usar el Lighthouse CLI del nodo.
Llamado Simorgh después del ave mitológica persa. El Simorgh es la amalgama de muchas aves (y en algunos relatos otros animales) en uno.
Afortunadamente, una metáfora que parecía adecuada para ofrecer todos los artículos de la BBC en una solución es quizás aún más apropiada a medida que la aplicación evoluciona para admitir más tipos de contenido. También es una clara referencia a la naturaleza internacional de nuestros equipos, pero también al deseo de garantizar que los artículos (y todo lo que haya seguido) funcione para los usuarios en todos los idiomas que admite la BBC.
También es un nombre único que es práctico y, más superficialmente, el pájaro es muy bonito.