proscenium
v0.18.0
proue · voir · nee · euh
nom : avant -scène
- la partie d'une scène de théâtre devant le rideau.
Proscenium traite votre code frontend et côté client comme des citoyens de première classe de votre application Rails et suppose un Internet « rapide par défaut ». Il regroupe et réduit JavaScript (+ JSX), TypeScript (+ TSX) et CSS en temps réel, à la demande et sans configuration.
Les points forts :
rails s !La mise en route dépend évidemment de si vous ajoutez Proscenium à une application Rails existante ou si vous en créez une nouvelle. Choisissez donc le guide approprié ci-dessous :
Ajoutez cette ligne au Gemfile de votre application Rails, et vous êtes prêt à partir :
gem 'proscenium'Veuillez noter que Proscenium est conçu uniquement pour être utilisé avec Rails.
Désormais, si vous démarrez votre application Rails, vous pouvez ouvrir n'importe quel code frontal (JS, CSS, etc.). Par exemple, un fichier app/assets/stylesheets/application.css est accessible sur https://localhost:3000/app/assets/stylesheets/application.css , qui sera regroupé, transformé et minifié [en production] en temps réel.
Proscenium estime que votre code frontend est tout aussi important que votre code backend, et n'est pas une réflexion après coup - ils devraient être des citoyens de première classe de votre application Rails. Ainsi, au lieu d'avoir à placer tous vos JS et CSS dans un répertoire "app/assets", puis de nécessiter un processus distinct pour les compiler ou les regrouper, placez-les simplement où vous le souhaitez dans votre application et exécutez simplement Rails !
Par exemple, si vous avez du JS requis par votre vue app/views/users/index.html.erb , créez simplement un fichier JS à côté de celui-ci dans app/views/users/index.js . Ou si vous avez du CSS utilisé par l'ensemble de votre application, placez-le dans app/views/layouts/application.css et chargez-le avec votre mise en page. Peut-être avez-vous quelques fonctions utilitaires JS, alors placez-les dans lib/utils.js .
Placez simplement vos JS(X) et CSS où vous le souhaitez, et ils seront servis par votre application Rails à partir de l'emplacement où vous les avez placés.
En utilisant les exemples ci-dessus...
app/views/users/index.js => https://localhost:3000/app/views/users/index.jsapp/views/layouts/application.css => https://localhost:3000/app/views/layouts/application.csslib/utils.js => https://localhost:3000/lib/utils.jsapp/components/menu_component.jsx => https://localhost:3000/app/components/menu_component.jsxconfig/properties.css => https://localhost:3000/config/properties.css Proscenium est mieux exploité lorsque vos ressources sont automatiquement chargées latéralement.
Avec Rails, vous chargez généralement de manière déclarative vos ressources JavaScript et CSS à l'aide des assistants javascript_include_tag et stylesheet_link_tag .
Par exemple, vous pouvez avoir un CSS « d'application » de niveau supérieur situé dans un fichier à l' /app/assets/stylesheets/application.css . De même, vous pouvez avoir du JavaScript global situé dans un fichier à l'adresse /app/javascript/application.js .
Vous incluriez manuellement et de manière déclarative ces deux fichiers dans la présentation de votre application, quelque chose comme ceci :
<%# /app/views/layouts/application.html.erb %>
<!DOCTYPE html >
< html >
< head >
< title > Hello World </ title >
<%= stylesheet_link_tag 'application' %> <!-- << Your app CSS -->
</ head >
< body >
<%= yield %>
<%= javascript_include_tag 'application' %> <!-- << Your app JS -->
</ body >
</ html >Maintenant, vous pouvez avoir du CSS et du JavaScript qui ne sont requis que par une vue spécifique et partiels, vous les chargeriez donc dans votre vue (ou mise en page), quelque chose comme ceci :
<%# /app/views/users/index.html.erb %>
<%= stylesheet_link_tag 'users' %>
<%= javascript_include_tag 'users' %>
<%# needed by the `users/_user.html.erb` partial %>
<%= javascript_include_tag '_user' %>
<% render @users %> Le principal problème est que vous devez garder une trace de tous ces actifs et vous assurer que chacun est chargé par toutes les vues qui les nécessitent, mais également éviter de les charger lorsqu'ils ne sont pas nécessaires. Cela peut être très pénible, surtout lorsque vous avez beaucoup de points de vue.
Lors du chargement latéral de votre JavaScript, Typescript et CSS avec Proscenium, ils sont automatiquement inclus aux côtés de vos vues, partiels, mises en page et composants, et uniquement en cas de besoin.
Le chargement latéral fonctionne en recherchant un fichier JS/TS/CSS portant le même nom que votre vue, partielle, mise en page ou composant. Par exemple, si vous avez une vue sur app/views/users/index.html.erb , alors Proscenium recherchera un fichier JS/TS/CSS dans app/views/users/index.js , app/views/users/index.ts ou app/views/users/index.css . S'il en trouve un, il l'inclura dans le code HTML de cette vue.
JSX est également pris en charge pour JavaScript et Typescript. Utilisez simplement l'extension .jsx ou .tsx au lieu de .js ou .ts .
Créez simplement un fichier JS et/ou CSS avec le même nom que n'importe quelle vue, partielle ou mise en page.
Continuons avec notre exemple de problème ci-dessus, où nous avons les atouts suivants
/app/assets/application.css/app/assets/application.js/app/assets/users.css/app/assets/users.js/app/assets/user.js La présentation de votre application se trouve dans /app/views/layouts/application.hml.erb , et la vue qui nécessite les ressources des utilisateurs se trouve dans /app/views/users/index.html.erb , déplacez donc vos ressources JS et CSS à côté d'elles. :
/app/views/layouts/application.css/app/views/layouts/application.js/app/views/users/index.css/app/views/users/index.js/app/views/users/_user.js (partiel) Maintenant, dans votre mise en page et votre vue, remplacez les assistants javascript_include_tag et stylesheet_link_tag par l'assistant include_asset de Proscenium. Quelque chose comme ça :
<!DOCTYPE html >
< html >
< head >
< title > Hello World </ title >
<%= include_assets # <-- %>
</ head >
< body >
<%= yield %>
</ body >
</ html > À chaque demande de page, Proscenium vérifiera si l'une de vos vues, mises en page et partiels a un fichier JS/TS/CSS du même nom, puis les inclura partout où vous avez placé l'assistant include_assets .
Désormais, vous n’aurez plus jamais à vous rappeler d’inclure vos actifs. Créez-les simplement avec vos vues, partiels et mises en page, et Proscenium s'occupera du reste.
Le chargement latéral est activé par défaut, mais vous pouvez le désactiver en définissant config.proscenium.side_load sur false dans votre /config/application.rb .
Il existe également des assistants include_stylesheets et include_javascripts pour vous permettre de contrôler où les ressources CSS et JS sont incluses dans le HTML. Ces assistants doivent être utilisés à la place de include_assets si vous souhaitez contrôler exactement où les actifs sont inclus.
Regrouper un fichier signifie intégrer toutes les dépendances importées dans le fichier lui-même. Ce processus est récursif, donc les dépendances (et ainsi de suite) seront également intégrées.
Proscenium sera groupé par défaut et en temps réel. Il n’y a donc pas d’étape de construction ou de précompilation distincte.
Proscenium prend en charge l'importation de JS, JSX, TS, TSX, CSS et SVG depuis NPM, par URL, votre application locale et même depuis d'autres Ruby Gems.
Les importations statiques ( import ) et dynamiques ( import() ) sont prises en charge pour JavaScript et TypeScript et peuvent être utilisées pour importer des fichiers JS, TS, JSX, TSX, JSON, CSS et SVG.
La règle at @import CSS est prise en charge pour CSS.
Les chemins d'importation ne sont actuellement regroupés que s'il s'agit d'une chaîne littérale ou d'un modèle global. Les autres formes de chemins d'importation ne sont pas regroupées et sont conservées textuellement dans la sortie générée. En effet, le regroupement est une opération de compilation et Proscenium ne prend pas en charge toutes les formes de résolution de chemin d'exécution.
Voici quelques exemples :
// Analyzable imports (will be bundled)
import "pkg" ;
import ( "pkg" ) ;
import ( `./locale- ${ foo } .json` ) ;
// Non-analyzable imports (will not be bundled)
import ( `pkg/ ${ foo } ` ) ;La façon de contourner les importations non analysables consiste à marquer le package contenant ce code problématique comme dégroupé afin qu'il ne soit pas inclus dans le bundle. Vous devrez ensuite vous assurer qu'une copie du package externe est disponible pour votre code fourni au moment de l'exécution.
node_modules ) Les importations nues (importations ne commençant pas par ./ , / , https:// , http:// ) sont entièrement prises en charge et utiliseront le gestionnaire de packages de votre choix (par exemple, NPM, Yarn, pnpm) via le fichier package.json situé à la racine de votre application Rails.
Installez le package que vous souhaitez importer à l'aide du gestionnaire de packages de votre choix...
npm install react
... puis importez-le comme vous le feriez pour n'importe quel autre package.
import React from "react" ;Et bien sûr, vous pouvez importer votre propre code, en utilisant des chemins relatifs ou absolus (l'extension de fichier est facultative et les chemins absolus utilisent votre racine Rails comme base) :
import utils from "/lib/utils" ;
import constants from "./constants" ;
import Header from "/app/components/header" ; @import "/lib/reset" ; Parfois, vous ne souhaitez pas regrouper une importation. Par exemple, vous voulez vous assurer qu’une seule instance de React est chargée. Dans ce cas, vous pouvez utiliser le préfixe unbundle
import React from "unbundle:react" ;Cela ne fonctionne que pour les importations nues et locales.
Vous pouvez également utiliser le préfixe unbundle dans votre mappe d'importation, ce qui garantit que toutes les importations d'un chemin particulier sont toujours dégroupées :
{
"imports" : {
"react" : " unbundle:react "
}
}Ensuite, importez simplement comme d'habitude :
import React from "react" ; [En cours]
L'importation de cartes pour JS et CSS est prise en charge dès le départ et fonctionne quel que soit le navigateur utilisé. En effet, la carte d'importation est analysée et résolue par Proscenium sur le serveur, plutôt que par le navigateur. C'est plus rapide et vous permet également d'utiliser des cartes d'importation dans des navigateurs qui ne les prennent pas encore en charge.
Si vous n'êtes pas familier avec les cartes d'importation, considérez-les comme un moyen de définir des alias.
Créez simplement config/import_map.json et spécifiez les importations que vous souhaitez utiliser. Par exemple:
{
"imports" : {
"react" : " https://esm.sh/[email protected] " ,
"start" : " /lib/start.js " ,
"common" : " /lib/common.css " ,
"@radix-ui/colors/" : " https://esm.sh/@radix-ui/[email protected]/ "
}
}En utilisant la carte d'importation ci-dessus, nous pouvons faire...
import { useCallback } from "react" ;
import startHere from "start" ;
import styles from "common" ;et pour CSS...
@import "common" ;
@import "@radix-ui/colors/blue.css" ; Vous pouvez également écrire votre carte d'importation en JavaScript au lieu de JSON. Ainsi, au lieu de config/import_map.json , créez config/import_map.js et définissez une fonction anonyme. Cette fonction accepte un seul argument environment .
( env ) => ( {
imports : {
react :
env === "development"
? "https://esm.sh/[email protected]?dev"
: "https://esm.sh/[email protected]" ,
} ,
} ) ; Les mappages sources peuvent faciliter le débogage de votre code. Ils codent les informations nécessaires pour traduire un décalage de ligne/colonne dans un fichier de sortie généré en un décalage de ligne/colonne dans le fichier d'entrée d'origine correspondant. Ceci est utile si votre code généré est suffisamment différent de votre code d'origine (par exemple, votre code d'origine est TypeScript ou vous avez activé la minification). Ceci est également utile si vous préférez consulter des fichiers individuels dans les outils de développement de votre navigateur plutôt qu'un gros fichier groupé.
La sortie de la carte source est prise en charge pour JavaScript et CSS. Chaque fichier est accompagné du lien vers la carte source. Par exemple:
//# sourceMappingURL=/app/views/layouts/application.js.mapLes outils de développement de votre navigateur devraient récupérer cela et charger automatiquement la carte source quand et où cela est nécessaire.
Vous pouvez importer du SVG depuis JS(X), qui regroupera le code source SVG. De plus, si vous importez depuis JSX ou TSX, le code source SVG sera rendu en tant que composant JSX/TSX.
Disponible en
>=0.10.0
Vous pouvez définir et accéder à n'importe quelle variable d'environnement à partir de votre JavaScript et Typescript sous l'espace de noms proscenium.env .
Pour des raisons de performances et de sécurité, vous devez déclarer les noms des variables d'environnement que vous souhaitez exposer dans votre fichier config/application.rb .
config . proscenium . env_vars = Set [ 'API_KEY' , 'SOME_SECRET_VARIABLE' ]
config . proscenium . env_vars << 'ANOTHER_API_KEY' Cela suppose que la variable d'environnement du même nom a déjà été définie. Sinon, vous devrez le définir vous-même soit dans votre code à l'aide de l'objet ENV de Ruby, soit dans votre shell.
Ces variables d'environnement déclarées seront remplacées par des expressions constantes, vous permettant d'utiliser ceci comme ceci :
console . log ( proscenium . env . RAILS_ENV ) ; // console.log("development")
console . log ( proscenium . env . RAILS_ENV === "development" ) ; // console.log(true) Les variables d'environnement RAILS_ENV et NODE_ENV seront toujours automatiquement déclarées pour vous.
En plus de cela, Proscenium fournit également une variable process.env.NODE_ENV , qui est définie sur la même valeur que proscenium.env.RAILS_ENV . Il est prévu pour supporter les outils existants de la communauté, qui s'appuient souvent sur cette variable.
Les variables d’environnement sont particulièrement puissantes pour faciliter le tremblement des arbres.
function start ( ) {
console . log ( "start" ) ;
}
function doSomethingDangerous ( ) {
console . log ( "resetDatabase" ) ;
}
proscenium . env . RAILS_ENV === "development" && doSomethingDangerous ( ) ;
start ( ) ; En développement, le code ci-dessus sera transformé en code suivant, en supprimant la définition et en appelant doSomethingDangerous() .
function start ( ) {
console . log ( "start" ) ;
}
start ( ) ;Veuillez noter que pour des raisons de sécurité, les variables d'environnement ne sont pas remplacées dans les importations d'URL.
Une variable d'environnement non définie sera remplacée par undefined .
console . log ( proscenium . env . UNKNOWN ) ; // console.log((void 0).UNKNOWN)Cela signifie que le code qui repose sur cela ne sera pas ébranlé. Vous pouvez contourner ce problème en utilisant l'opérateur de chaînage facultatif :
if ( typeof proscenium . env ?. UNKNOWN !== "undefined" ) {
// do something if UNKNOWN is defined
} Une prise en charge de base est fournie pour importer vos fichiers de paramètres régionaux Rails à partir de config/locales/*.yml , et les exporter au format JSON.
import translations from "@proscenium/i18n" ;
// translations.en.* Par défaut, la sortie de Proscenium profitera de toutes les fonctionnalités JS modernes de la spécification ES2022 et antérieures. Par exemple, a !== void 0 && a !== null ? a : b deviendra a ?? b lors de la minification (activée par défaut en production), qui utilise la syntaxe de la version ES2020 de JavaScript. Toute fonctionnalité de syntaxe qui n'est pas prise en charge par ES2020 sera transformée en une ancienne syntaxe JavaScript plus largement prise en charge.
Le tremblement d'arbre est le terme que la communauté JavaScript utilise pour l'élimination du code mort, une optimisation courante du compilateur qui supprime automatiquement le code inaccessible. Le tremblement des arbres est activé par défaut dans Proscenium.
function one ( ) {
console . log ( "one" ) ;
}
function two ( ) {
console . log ( "two" ) ;
}
one ( ) ; Le code ci-dessus sera transformé en code suivant, en supprimant two() , car il n'est jamais appelé.
function one ( ) {
console . log ( "one" ) ;
}
one ( ) ;Disponible en
>=0.10.0.
Les ressources chargées latéralement sont automatiquement divisées en code. Cela signifie que si vous avez un fichier importé et utilisé plusieurs fois, et par différents fichiers, il sera divisé en un fichier distinct.
A titre d'exemple :
// /lib/son.js
import father from "./father" ;
father ( ) + " and Son" ; // /lib/daughter.js
import father from "./father" ;
father ( ) + " and Daughter" ; // /lib/father.js
export default ( ) => "Father" ; son.js et daughter.js importent father.js , de sorte que le fils et la fille incluent généralement une copie du père, ce qui entraîne une duplication de code et des tailles de bundle plus grandes.
Si ces fichiers sont chargés latéralement, alors father.js sera divisé en un fichier ou un morceau séparé et téléchargé une seule fois.
Le code partagé entre plusieurs points d’entrée est divisé dans un fichier partagé distinct que les deux points d’entrée importent. De cette façon, si l'utilisateur navigue d'abord vers une page puis vers une autre page, il n'a pas besoin de télécharger tout le JavaScript de la deuxième page à partir de zéro si la partie partagée a déjà été téléchargée et mise en cache par son navigateur.
Le code référencé via une expression import() asynchrone sera divisé dans un fichier séparé et chargé uniquement lorsque cette expression sera évaluée. Cela vous permet d'améliorer le temps de téléchargement initial de votre application en téléchargeant uniquement le code dont vous avez besoin au démarrage, puis en téléchargeant paresseusement du code supplémentaire si nécessaire ultérieurement.
Sans fractionnement de code, une expression import() devient Promise.resolve().then(() => require()) à la place. Cela préserve toujours la sémantique asynchrone de l'expression, mais cela signifie que le code importé est inclus dans le même bundle au lieu d'être divisé dans un fichier séparé.
Le fractionnement du code est activé par défaut. Vous pouvez le désactiver en définissant l'option de configuration code_splitting sur false dans le /config/application.rb de votre application :
config . proscenium . code_splitting = falseIl y a quelques mises en garde importantes en ce qui concerne JavaScript. Ceux-ci sont détaillés sur le site esbuild.
CSS est un type de contenu de première classe dans Proscenium, ce qui signifie qu'il peut regrouper des fichiers CSS directement sans avoir besoin d'importer votre CSS à partir du code JavaScript. Vous pouvez @import d'autres fichiers CSS et référencer des fichiers d'images et de polices avec url() et Proscenium regroupera le tout.
Notez que par défaut, la sortie de Proscenium profitera de toutes les fonctionnalités CSS modernes. Par exemple, color: rgba(255, 0, 0, 0.4) deviendra color: #f006 après minification en production, qui utilise la syntaxe du CSS Color Module Niveau 4.
La nouvelle syntaxe d'imbrication CSS est prise en charge et transformée en CSS non imbriquée pour les anciens navigateurs.
Proscenium insérera également automatiquement les préfixes des fournisseurs afin que votre CSS fonctionne dans les anciens navigateurs.
Vous pouvez également importer du CSS depuis JavaScript. Lorsque vous faites cela, Proscenium ajoutera automatiquement chaque feuille de style à l'en-tête du document en tant qu'élément <link> .
import "./button.css" ;
export let Button = ( { text } ) => {
return < div className = "button" > { text } < / div > ;
} ; Proscenium implémente un sous-ensemble de modules CSS. Il prend en charge les mots-clés :local et :global , mais pas la propriété composes . (il est recommandé d'utiliser des mixins au lieu de composes , car ils fonctionneront partout, même dans les fichiers CSS simples.)
Donnez à n'importe quel fichier CSS une extension .module.css et Proscenium le traitera comme un module CSS, transformant tous les noms de classe avec un suffixe unique au fichier.
. title {
font-size : 20 em ;
}L'entrée ci-dessus produit :
. title-5564cdbb {
font-size : 20 em ;
}Vous disposez désormais d’un nom de classe unique que vous pouvez utiliser à peu près n’importe où.
Vous pouvez référencer des modules CSS à partir de vos vues, partiels et mises en page Rails à l'aide de l'assistant css_module , qui accepte un ou plusieurs noms de classe et renverra les noms de modules CSS équivalents - le nom de classe avec le suffixe unique ajouté.
Avec la configuration du chargement latéral, vous pouvez utiliser l'assistant css_module comme suit.
< div >
< h1 class =" <%= css_module :hello_title %> " > Hello World </ h1 >
< p class =" <%= css_module :body , paragraph : %> " >
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
</ p >
</ div > css_module accepte plusieurs noms de classe et renverra une chaîne de noms de modules CSS transformés, séparés par des espaces.
css_module :my_module_name
# => "my_module_name-ABCD1234"Vous pouvez même référencer une classe à partir de n'importe quel fichier CSS en transmettant le chemin URL du fichier, comme préfixe du nom de la classe. Cela chargera automatiquement la feuille de style.
css_module '/app/components/button.css@big_button'
# => "big_button"Il prend également en charge les packages NPM (déjà installés dans /node_modules) :
css_module 'mypackage/button@big_button'
# => "big_button" css_module accepte également un argument de mot-clé path , qui vous permet de spécifier le chemin d'accès au fichier CSS. Notez que cela utilisera le chemin donné pour tous les noms de classe transmis à cette instance de css_module .
css_module :my_module_name , path : Rails . root . join ( 'app/components/button.css' ) L'importation d'un module CSS depuis JS ajoutera automatiquement la feuille de style à l'en-tête du document. Et le résultat de l'importation sera un objet de classe CSS vers les noms de modules.
import styles from "./styles.module.css" ;
// styles == { header: 'header-5564cdbb' }Il est important de noter que l'objet exporté des noms de modules CSS est en réalité un objet proxy JavaScript. Donc déstructurer l’objet ne fonctionnera pas. Au lieu de cela, vous devez accéder directement aux propriétés.
De plus, l'importation d'un module CSS dans un autre module CSS entraînera la même chaîne de résumé pour toutes les classes.
Proscenium fournit des fonctionnalités permettant d'inclure ou de "mélanger" une ou plusieurs classes CSS dans une autre. Ceci est similaire à la propriété composes des modules CSS, mais fonctionne partout et ne se limite pas aux modules CSS.
Les mixins CSS sont pris en charge à l'aide des règles at @define-mixin et @mixin .
Un mixin est défini à l'aide de la règle at @define-mixin . Donnez-lui un nom, qui doit respecter la sémantique du nom de classe, et déclarez vos règles :
// /lib/mixins.css
@define-mixin bigText {
font-size : 50 px ;
} Utilisez un mixin en utilisant la règle at @mixin . Passez-lui le nom du mixin que vous souhaitez utiliser et l'url où le mixin est déclaré. L'URL est utilisée pour résoudre le mixin et peut être relative, absolue, une URL ou même provenir d'un package NPM.
// /app/views/layouts/application.css
p {
@mixin bigText from url ( "/lib/mixins.css" );
color : red;
}Ce qui précède produit ce résultat :
p {
font-size : 50 px ;
color : red;
}Les mixins peuvent être déclarés dans n'importe quel fichier CSS. Il n'est pas nécessaire de les déclarer dans le même fichier que celui où ils sont utilisés. cependant, si vous déclarez et utilisez un mixin dans le même fichier, vous n'avez pas besoin de spécifier l'URL de l'endroit où le mixin est déclaré.
@define-mixin bigText {
font-size : 50 px ;
}
p {
@mixin bigText;
color : red;
}Les modules CSS et Mixins fonctionnent parfaitement ensemble. Vous pouvez inclure un mixin dans un module CSS.
Il y a quelques mises en garde importantes en ce qui concerne CSS. Ceux-ci sont détaillés sur le site esbuild.
Typescript et TSX sont pris en charge dès le départ et disposent d'une prise en charge intégrée pour l'analyse de la syntaxe TypeScript et la suppression des annotations de type. Renommez simplement vos fichiers en .ts ou .tsx et vous êtes prêt à partir.
Veuillez noter que Proscenium n'effectue aucune vérification de type, vous devrez donc toujours exécuter tsc -noEmit en parallèle avec Proscenium pour vérifier les types.
Il y a quelques mises en garde importantes en ce qui concerne Typescript. Ceux-ci sont détaillés sur le site esbuild.
L'utilisation de la syntaxe JSX nécessite généralement que vous importiez manuellement la bibliothèque JSX que vous utilisez. Par exemple, si vous utilisez React, par défaut vous devrez importer React dans chaque fichier JSX comme ceci :
import * as React from "react" ;
render ( < div / > ) ; En effet, la transformation JSX transforme la syntaxe JSX en un appel à React.createElement mais elle n'importe rien elle-même, donc la variable React n'est pas automatiquement présente.
Proscenium génère ces instructions d'importation pour vous. Gardez à l'esprit que cela change également complètement le fonctionnement de la transformation JSX, cela peut donc casser votre code si vous utilisez une bibliothèque JSX qui n'est pas React.
Dans un avenir [pas trop lointain], vous pourrez configurer Proscenium pour utiliser une bibliothèque JSX différente, ou désactiver complètement cette importation automatique.
L'importation de fichiers .json analyse le fichier JSON dans un objet JavaScript et exporte l'objet comme exportation par défaut. Son utilisation ressemble à ceci :
import object from "./example.json" ;
console . log ( object ) ;En plus de l'exportation par défaut, il existe également des exportations nommées pour chaque propriété de niveau supérieur dans l'objet JSON. L'importation directe d'une exportation nommée signifie que Proscenium peut automatiquement supprimer les parties inutilisées du fichier JSON du bundle, ne laissant que les exportations nommées que vous avez réellement utilisées. Par exemple, ce code n'inclura le champ de version que lorsqu'il sera groupé :
import { version } from "./package.json" ;
console . log ( version ) ; Phlex est un framework permettant de créer des vues rapides, réutilisables et testables en Ruby pur. Proscenium fonctionne parfaitement avec Phlex, avec prise en charge du chargement latéral, des modules CSS, etc. Écrivez simplement vos classes Phlex et héritez de Proscenium::Phlex .
class MyView < Proscenium :: Phlex
def view_template
h1 { 'Hello World' }
end
end Dans vos mises en page, incluez Proscenium::Phlex::AssetInclusions et appelez l'assistant include_assets .
class ApplicationLayout < Proscenium :: Phlex
include Proscenium :: Phlex :: AssetInclusions # <--
def view_template ( & )
doctype
html do
head do
title { 'My Awesome App' }
include_assets # <--
end
body ( & )
end
end
end Vous pouvez spécifiquement inclure des actifs CCS et JS à l'aide des assistants include_stylesheets et include_javascripts , vous permettant de contrôler où ils sont inclus dans le HTML.
Toute classe Phlex qui hérite de Proscenium::Phlex sera automatiquement chargée latéralement.
Les modules CSS sont entièrement pris en charge dans les classes Phlex, avec accès à l'assistant css_module si vous en avez besoin. Cependant, il existe un moyen meilleur et plus simple de référencer les classes de modules CSS dans vos classes Phlex.
Dans vos classes Phlex, tous les noms de classe commençant par @ seront traités comme une classe de module CSS.
# /app/views/users/show_view.rb
class Users :: ShowView < Proscenium :: Phlex
def 
