proscenium
v0.18.0
proa · ver · nee · uhm
substantivo : proscênio
- a parte de um palco de teatro em frente à cortina.
O Proscenium trata seu frontend e código do lado do cliente como cidadãos de primeira classe do seu aplicativo Rails e assume uma internet "rápida por padrão". Ele agrupa e minimiza JavaScript (+ JSX), TypeScript (+TSX) e CSS em tempo real, sob demanda e sem configuração.
Os destaques:
rails s !Obviamente, começar depende se você está adicionando Proscenium a um aplicativo Rails existente ou criando um novo. Portanto, escolha o guia apropriado abaixo:
Adicione esta linha ao Gemfile da sua aplicação Rails e pronto:
gem 'proscenium'Observe que o Proscenium foi projetado exclusivamente para uso com Rails.
Agora, se você iniciar seu aplicativo Rails, poderá abrir qualquer código front end (JS, CSS, etc.). Por exemplo, um arquivo em app/assets/stylesheets/application.css pode ser acessado em https://localhost:3000/app/assets/stylesheets/application.css , que será agrupado, transformado e reduzido [em produção] em tempo real.
A Proscenium acredita que seu código frontend é tão importante quanto seu código backend, e não é uma reflexão tardia - eles devem ser cidadãos de primeira classe de seu aplicativo Rails. Então, em vez de ter que jogar todo o seu JS e CSS em um diretório "app/assets" e, em seguida, exigir um processo separado para compilar ou empacotar, basta colocá-los onde quiser dentro do seu aplicativo e executar o Rails!
Por exemplo, se você tiver algum JS exigido pela sua visualização app/views/users/index.html.erb , basta criar um arquivo JS junto com ele em app/views/users/index.js . Ou se você tiver algum CSS usado por todo o seu aplicativo, coloque-o em app/views/layouts/application.css e carregue-o junto com seu layout. Talvez você tenha algumas funções utilitárias JS, então coloque-as em lib/utils.js .
Basta colocar seu JS(X) e CSS onde quiser e eles serão servidos pelo seu aplicativo Rails a partir do local onde você os colocou.
Usando os exemplos acima...
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 O Proscenium é melhor experimentado quando seus ativos são carregados automaticamente.
Com Rails você normalmente carregaria declarativamente seus ativos JavaScript e CSS usando os auxiliares javascript_include_tag e stylesheet_link_tag .
Por exemplo, você pode ter CSS de "aplicativo" de nível superior localizado em um arquivo em /app/assets/stylesheets/application.css . Da mesma forma, você pode ter algum JavaScript global localizado em um arquivo em /app/javascript/application.js .
Você incluiria manual e declarativamente esses dois arquivos no layout do seu aplicativo, mais ou menos assim:
<%# /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 >Agora, você pode ter algum CSS e JavaScript que é exigido apenas por uma visualização específica e parcial, então você carregaria isso em sua visualização (ou layout), algo assim:
<%# /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 %> O principal problema é que você precisa acompanhar todos esses ativos e garantir que cada um seja carregado por todas as visualizações que os exigem, mas também evitar carregá-los quando não forem necessários. Isso pode ser uma verdadeira dor, especialmente quando você tem muitas visualizações.
Ao carregar seu JavaScript, Typescript e CSS com Proscenium, eles são automaticamente incluídos junto com suas visualizações, parciais, layouts e componentes, e somente quando necessário.
O carregamento lateral funciona procurando um arquivo JS/TS/CSS com o mesmo nome da sua visualização, parcial, layout ou componente. Por exemplo, se você tiver uma visualização em app/views/users/index.html.erb , o Proscenium procurará um arquivo JS/TS/CSS em app/views/users/index.js , app/views/users/index.ts ou app/views/users/index.css . Se encontrar um, ele o incluirá no HTML dessa visualização.
JSX também é compatível com JavaScript e Typescript. Basta usar a extensão .jsx ou .tsx em vez de .js ou .ts .
Basta criar um arquivo JS e/ou CSS com o mesmo nome de qualquer visualização, parcial ou layout.
Vamos continuar com nosso exemplo de problema acima, onde temos os seguintes ativos
/app/assets/application.css/app/assets/application.js/app/assets/users.css/app/assets/users.js/app/assets/user.js O layout do seu aplicativo está em /app/views/layouts/application.hml.erb , e a visualização que precisa dos ativos dos usuários está em /app/views/users/index.html.erb , então mova seus ativos JS e CSS junto com eles :
/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 (parcial) Agora, em seu layout e visualização, substitua os auxiliares javascript_include_tag e stylesheet_link_tag pelo auxiliar include_asset do Proscenium. Algo assim:
<!DOCTYPE html >
< html >
< head >
< title > Hello World </ title >
<%= include_assets # <-- %>
</ head >
< body >
<%= yield %>
</ body >
</ html > Em cada solicitação de página, o Proscenium verificará se alguma de suas visualizações, layouts e parciais tem um arquivo JS/TS/CSS com o mesmo nome e, em seguida, os incluirá onde quer que você tenha colocado o auxiliar include_assets .
Agora você nunca mais precisará se lembrar de incluir seus ativos novamente. Basta criá-los junto com suas visualizações, parciais e layouts, e o Proscenium cuidará do resto.
O carregamento lateral está habilitado por padrão, mas você pode desabilitá-lo definindo config.proscenium.side_load como false em seu /config/application.rb .
Existem também auxiliares include_stylesheets e include_javascripts para permitir que você controle onde os ativos CSS e JS são incluídos no HTML. Esses auxiliares devem ser usados em vez de include_assets se você quiser controlar exatamente onde os ativos serão incluídos.
Agrupar um arquivo significa incorporar quaisquer dependências importadas no próprio arquivo. Este processo é recursivo, portanto as dependências das dependências (e assim por diante) também serão incorporadas.
O Proscenium será agrupado por padrão e em tempo real. Portanto, não há etapa de construção ou pré-compilação separada.
O Proscenium suporta a importação de JS, JSX, TS, TSX, CSS e SVG do NPM, por URL, seu aplicativo local e até mesmo de outras Ruby Gems.
Ambas as importações estáticas ( import ) e dinâmicas ( import() ) são suportadas para JavaScript e TypeScript e podem ser usadas para importar arquivos JS, TS, JSX, TSX, JSON, CSS e SVG.
A regra @import CSS é suportada para CSS.
Atualmente, os caminhos de importação só são agrupados se forem uma string literal ou um padrão glob. Outras formas de caminhos de importação não são agrupadas e, em vez disso, são preservadas literalmente na saída gerada. Isso ocorre porque o empacotamento é uma operação em tempo de compilação e o Proscenium não oferece suporte a todas as formas de resolução de caminho em tempo de execução.
Aqui estão alguns exemplos:
// Analyzable imports (will be bundled)
import "pkg" ;
import ( "pkg" ) ;
import ( `./locale- ${ foo } .json` ) ;
// Non-analyzable imports (will not be bundled)
import ( `pkg/ ${ foo } ` ) ;A maneira de contornar importações não analisáveis é marcar o pacote que contém esse código problemático como desagregado, para que não seja incluído no pacote. Você precisará então garantir que uma cópia do pacote externo esteja disponível para o código do pacote em tempo de execução.
node_modules ) As importações simples (importações que não começam com ./ , / , https:// , http:// ) são totalmente suportadas e usarão o gerenciador de pacotes de sua escolha (por exemplo, NPM, Yarn, pnpm) por meio do arquivo package.json localizado na raiz do seu aplicativo Rails.
Instale o pacote que deseja importar usando o gerenciador de pacotes de sua preferência...
npm install react
...e depois importe-o como faria com qualquer outro pacote.
import React from "react" ;E é claro que você pode importar seu próprio código, usando caminhos relativos ou absolutos (a extensão do arquivo é opcional, e os caminhos absolutos usam sua raiz do Rails como base):
import utils from "/lib/utils" ;
import constants from "./constants" ;
import Header from "/app/components/header" ; @import "/lib/reset" ; Às vezes você não deseja agrupar uma importação. Por exemplo, você deseja garantir que apenas uma instância do React seja carregada. Nestes casos, você pode usar o prefixo unbundle
import React from "unbundle:react" ;Isso funciona apenas em importações simples e locais.
Você também pode usar o prefixo unbundle no seu mapa de importação, o que garante que todas as importações de um caminho específico sejam sempre desagregadas:
{
"imports" : {
"react" : " unbundle:react "
}
}Depois é só importar normalmente:
import React from "react" ; [WIP]
A importação de mapas para JS e CSS é suportada imediatamente e funciona independentemente do navegador que está sendo usado. Isso ocorre porque o mapa de importação é analisado e resolvido pelo Proscenium no servidor, e não pelo navegador. Isso é mais rápido e também permite que você importe mapas em navegadores que ainda não os suportam.
Se você não estiver familiarizado com mapas de importação, pense neles como uma forma de definir aliases.
Basta criar config/import_map.json e especificar as importações que deseja usar. Por exemplo:
{
"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]/ "
}
}Usando o mapa de importação acima, podemos fazer...
import { useCallback } from "react" ;
import startHere from "start" ;
import styles from "common" ;e para CSS...
@import "common" ;
@import "@radix-ui/colors/blue.css" ; Você também pode escrever seu mapa de importação em JavaScript em vez de JSON. Portanto, em vez de config/import_map.json , crie config/import_map.js e defina uma função anônima. Esta função aceita um único argumento environment .
( env ) => ( {
imports : {
react :
env === "development"
? "https://esm.sh/[email protected]?dev"
: "https://esm.sh/[email protected]" ,
} ,
} ) ; Os mapas de origem podem facilitar a depuração do seu código. Eles codificam as informações necessárias para traduzir de um deslocamento de linha/coluna em um arquivo de saída gerado de volta para um deslocamento de linha/coluna no arquivo de entrada original correspondente. Isso é útil se o código gerado for suficientemente diferente do código original (por exemplo, seu código original é TypeScript ou você ativou a minificação). Isso também é útil se você preferir ver arquivos individuais nas ferramentas de desenvolvedor do seu navegador, em vez de um grande arquivo agrupado.
A saída do mapa de origem é compatível com JavaScript e CSS. Cada arquivo é anexado com o link para o mapa de origem. Por exemplo:
//# sourceMappingURL=/app/views/layouts/application.js.mapAs ferramentas de desenvolvimento do seu navegador devem captar isso e carregar automaticamente o mapa de origem quando e onde necessário.
Você pode importar SVG de JS(X), que agrupará o código-fonte SVG. Além disso, se importar de JSX ou TSX, o código-fonte SVG será renderizado como um componente JSX/TSX.
Disponível em
>=0.10.0
Você pode definir e acessar qualquer variável de ambiente de seu JavaScript e Typescript no namespace proscenium.env .
Por motivos de desempenho e segurança, você deve declarar os nomes das variáveis de ambiente que deseja expor em seu arquivo config/application.rb .
config . proscenium . env_vars = Set [ 'API_KEY' , 'SOME_SECRET_VARIABLE' ]
config . proscenium . env_vars << 'ANOTHER_API_KEY' Isso pressupõe que a variável de ambiente com o mesmo nome já tenha sido definida. Caso contrário, você mesmo precisará defini-lo em seu código usando o objeto ENV do Ruby ou em seu shell.
Essas variáveis de ambiente declaradas serão substituídas por expressões constantes, permitindo que você use assim:
console . log ( proscenium . env . RAILS_ENV ) ; // console.log("development")
console . log ( proscenium . env . RAILS_ENV === "development" ) ; // console.log(true) As variáveis de ambiente RAILS_ENV e NODE_ENV sempre serão declaradas automaticamente para você.
Além disso, o Proscenium também fornece uma variável process.env.NODE_ENV , que é definida com o mesmo valor que proscenium.env.RAILS_ENV . É fornecido para apoiar as ferramentas existentes na comunidade, que muitas vezes dependem desta variável.
As variáveis ambientais são particularmente poderosas para ajudar no tremor das árvores.
function start ( ) {
console . log ( "start" ) ;
}
function doSomethingDangerous ( ) {
console . log ( "resetDatabase" ) ;
}
proscenium . env . RAILS_ENV === "development" && doSomethingDangerous ( ) ;
start ( ) ; No desenvolvimento, o código acima será transformado no código a seguir, descartando a definição e chamando doSomethingDangerous() .
function start ( ) {
console . log ( "start" ) ;
}
start ( ) ;Observe que, por motivos de segurança, as variáveis de ambiente não são substituídas nas importações de URL.
Uma variável de ambiente indefinida será substituída por undefined .
console . log ( proscenium . env . UNKNOWN ) ; // console.log((void 0).UNKNOWN)Isso significa que o código que depende disso não será abalado. Você pode contornar isso usando o operador de encadeamento opcional:
if ( typeof proscenium . env ?. UNKNOWN !== "undefined" ) {
// do something if UNKNOWN is defined
} Suporte básico é fornecido para importar seus arquivos de localidade Rails de config/locales/*.yml , exportando-os como JSON.
import translations from "@proscenium/i18n" ;
// translations.en.* Por padrão, a saída do Proscenium aproveitará todos os recursos JS modernos da especificação ES2022 e anteriores. Por exemplo, a !== void 0 && a !== null ? a : b se tornará a ?? b ao minificar (habilitado por padrão na produção), que faz uso da sintaxe da versão ES2020 do JavaScript. Qualquer recurso de sintaxe que não seja compatível com ES2020 será transformado em uma sintaxe JavaScript mais antiga, com suporte mais amplo.
Tree shake é o termo que a comunidade JavaScript usa para eliminação de código morto, uma otimização comum do compilador que remove automaticamente código inacessível. A agitação da árvore está habilitada por padrão no Proscenium.
function one ( ) {
console . log ( "one" ) ;
}
function two ( ) {
console . log ( "two" ) ;
}
one ( ) ; O código acima será transformado no código a seguir, descartando two() , pois nunca é chamado.
function one ( ) {
console . log ( "one" ) ;
}
one ( ) ;Disponível em
>=0.10.0.
Os ativos carregados lateralmente são automaticamente divididos em código. Isso significa que se você tiver um arquivo que foi importado e usado várias vezes e por arquivos diferentes, ele será dividido em um arquivo separado.
Por exemplo:
// /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" ; Tanto son.js quanto daughter.js importam father.js , portanto, filho e filha geralmente incluiriam uma cópia de pai, resultando em código duplicado e tamanhos de pacote maiores.
Se esses arquivos forem carregados lateralmente, father.js será dividido em um arquivo ou bloco separado e baixado apenas uma vez.
O código compartilhado entre vários pontos de entrada é dividido em um arquivo compartilhado separado que ambos os pontos de entrada importam. Dessa forma, se o usuário navegar primeiro para uma página e depois para outra, ele não precisará baixar todo o JavaScript da segunda página do zero se a parte compartilhada já tiver sido baixada e armazenada em cache pelo navegador.
O código referenciado por meio de uma expressão assíncrona import() será dividido em um arquivo separado e carregado somente quando essa expressão for avaliada. Isso permite que você melhore o tempo de download inicial do seu aplicativo baixando apenas o código necessário na inicialização e, em seguida, baixando lentamente o código adicional, se necessário posteriormente.
Sem divisão de código, uma expressão import() se torna Promise.resolve().then(() => require()) em vez disso. Isso ainda preserva a semântica assíncrona da expressão, mas significa que o código importado é incluído no mesmo pacote em vez de ser dividido em um arquivo separado.
A divisão de código está habilitada por padrão. Você pode desativá-lo definindo a opção de configuração code_splitting como false no /config/application.rb do seu aplicativo:
config . proscenium . code_splitting = falseExistem algumas advertências importantes no que diz respeito ao JavaScript. Eles estão detalhados no site esbuild.
CSS é um tipo de conteúdo de primeira classe no Proscenium, o que significa que ele pode agrupar arquivos CSS diretamente, sem a necessidade de importar seu CSS do código JavaScript. Você pode @import outros arquivos CSS e fazer referência a arquivos de imagem e fonte com url() e o Proscenium agrupará tudo.
Observe que, por padrão, a saída do Proscenium aproveitará todas as vantagens de todos os recursos CSS modernos. Por exemplo, color: rgba(255, 0, 0, 0.4) se tornará color: #f006 após a redução na produção, que faz uso da sintaxe do CSS Color Module Level 4.
A nova sintaxe de aninhamento CSS é suportada e transformada em CSS não aninhado para navegadores mais antigos.
O Proscenium também inserirá automaticamente prefixos de fornecedores para que seu CSS funcione em navegadores mais antigos.
Você também pode importar CSS de JavaScript. Ao fazer isso, o Proscenium anexará automaticamente cada folha de estilo ao cabeçalho do documento como um elemento <link> .
import "./button.css" ;
export let Button = ( { text } ) => {
return < div className = "button" > { text } < / div > ;
} ; Proscenium implementa um subconjunto de módulos CSS. Ele suporta as palavras-chave :local e :global , mas não a propriedade composes . (é recomendado que você use mixins em vez de composes , pois eles funcionarão em qualquer lugar, mesmo em arquivos CSS simples.)
Dê a qualquer arquivo CSS uma extensão .module.css e o Proscenium o tratará como um Módulo CSS, transformando todos os nomes de classe com um sufixo exclusivo para o arquivo.
. title {
font-size : 20 em ;
}A entrada acima produz:
. title-5564cdbb {
font-size : 20 em ;
}Agora você tem um nome de classe exclusivo que pode ser usado em praticamente qualquer lugar.
Você pode referenciar módulos CSS de suas visualizações, parciais e layouts do Rails usando o auxiliar css_module , que aceita um ou mais nomes de classes e retornará os nomes de módulos CSS equivalentes - o nome da classe com o sufixo exclusivo anexado.
Com a configuração de carregamento lateral, você pode usar o auxiliar css_module da seguinte maneira.
< 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 aceita vários nomes de classes e retornará uma string separada por espaços de nomes de módulos CSS transformados.
css_module :my_module_name
# => "my_module_name-ABCD1234"Você pode até fazer referência a uma classe de qualquer arquivo CSS passando o caminho da URL para o arquivo, como um prefixo do nome da classe. Fazer isso carregará automaticamente a folha de estilo.
css_module '/app/components/button.css@big_button'
# => "big_button"Também suporta pacotes NPM (já instalados em /node_modules):
css_module 'mypackage/button@big_button'
# => "big_button" css_module também aceita um argumento de palavra-chave path , que permite especificar o caminho para o arquivo CSS. Observe que isso usará o caminho fornecido para todos os nomes de classes passados para aquela instância de css_module .
css_module :my_module_name , path : Rails . root . join ( 'app/components/button.css' ) Importar um módulo CSS de JS anexará automaticamente a folha de estilo ao cabeçalho do documento. E o resultado da importação será um objeto de classe CSS para nomes de módulos.
import styles from "./styles.module.css" ;
// styles == { header: 'header-5564cdbb' }É importante observar que o objeto exportado dos nomes dos módulos CSS é, na verdade, um objeto JavaScript Proxy. Portanto, desestruturar o objeto não funcionará. Em vez disso, você deve acessar as propriedades diretamente.
Além disso, importar um módulo CSS para outro módulo CSS resultará na mesma string de resumo para todas as classes.
O Proscenium fornece funcionalidade para incluir ou "misturar" uma ou mais classes CSS em outra. Isso é semelhante à propriedade composes dos Módulos CSS, mas funciona em qualquer lugar e não está limitado aos Módulos CSS.
Mixins CSS são suportados usando as regras @define-mixin e @mixin .
Um mixin é definido usando a regra @define-mixin . Passe um nome, que deve aderir à semântica do nome da classe, e declare suas regras:
// /lib/mixins.css
@define-mixin bigText {
font-size : 50 px ;
} Use um mixin usando a regra @mixin . Passe nele o nome do mixin que deseja usar e a url onde o mixin está declarado. A url é usada para resolver o mixin e pode ser relativa, absoluta, uma URL ou até mesmo de um pacote NPM.
// /app/views/layouts/application.css
p {
@mixin bigText from url ( "/lib/mixins.css" );
color : red;
}O acima produz esta saída:
p {
font-size : 50 px ;
color : red;
}Mixins podem ser declarados em qualquer arquivo CSS. Eles não precisam ser declarados no mesmo arquivo onde são usados. entretanto, se você declarar e usar um mixin no mesmo arquivo, não será necessário especificar a URL de onde o mixin foi declarado.
@define-mixin bigText {
font-size : 50 px ;
}
p {
@mixin bigText;
color : red;
}Módulos CSS e Mixins funcionam perfeitamente juntos. Você pode incluir um mixin em um módulo CSS.
Existem algumas advertências importantes no que diz respeito ao CSS. Eles estão detalhados no site esbuild.
Typescript e TSX são suportados imediatamente e possuem suporte integrado para analisar a sintaxe TypeScript e descartar as anotações de tipo. Basta renomear seus arquivos para .ts ou .tsx e pronto.
Observe que o Proscenium não faz nenhuma verificação de tipo, então você ainda precisará executar tsc -noEmit em paralelo com o Proscenium para verificar os tipos.
Existem algumas advertências importantes no que diz respeito ao Typescript. Eles estão detalhados no site esbuild.
O uso da sintaxe JSX geralmente requer a importação manual da biblioteca JSX que você está usando. Por exemplo, se você estiver usando o React, por padrão você precisará importar o React para cada arquivo JSX assim:
import * as React from "react" ;
render ( < div / > ) ; Isso ocorre porque a transformação JSX transforma a sintaxe JSX em uma chamada para React.createElement , mas ela própria não importa nada, portanto a variável React não está presente automaticamente.
O Proscenium gera essas declarações de importação para você. Tenha em mente que isso também muda completamente o funcionamento da transformação JSX, portanto, seu código pode quebrar se você estiver usando uma biblioteca JSX que não seja React.
Em um futuro [não muito distante], você poderá configurar o Proscenium para usar uma biblioteca JSX diferente ou desabilitar completamente esta importação automática.
A importação de arquivos .json analisa o arquivo JSON em um objeto JavaScript e exporta o objeto como exportação padrão. Usá-lo é mais ou menos assim:
import object from "./example.json" ;
console . log ( object ) ;Além da exportação padrão, também há exportações nomeadas para cada propriedade de nível superior no objeto JSON. Importar uma exportação nomeada diretamente significa que o Proscenium pode remover automaticamente partes não utilizadas do arquivo JSON do pacote, deixando apenas as exportações nomeadas que você realmente usou. Por exemplo, este código incluirá apenas o campo de versão quando empacotado:
import { version } from "./package.json" ;
console . log ( version ) ; Phlex é uma estrutura para construir visualizações rápidas, reutilizáveis e testáveis em Ruby puro. Proscenium funciona perfeitamente com Phlex, com suporte para carregamento lateral, módulos CSS e muito mais. Simplesmente escreva suas classes Phlex e herde de Proscenium::Phlex .
class MyView < Proscenium :: Phlex
def view_template
h1 { 'Hello World' }
end
end Em seus layouts, inclua Proscenium::Phlex::AssetInclusions e chame o auxiliar 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 Você pode incluir especificamente ativos CCS e JS usando os auxiliares include_stylesheets e include_javascripts , permitindo controlar onde eles serão incluídos no HTML.
Qualquer classe Phlex que herde Proscenium::Phlex será automaticamente carregada lateralmente.
Módulos CSS são totalmente suportados em classes Phlex, com acesso ao auxiliar css_module se necessário. No entanto, existe uma maneira melhor e mais simples de fazer referência às classes do módulo CSS em suas classes Phlex.
Dentro de suas classes Phlex, qualquer nome de classe que comece com @ será tratado como uma classe de módulo CSS.
# /app/views/users/show_view.rb
class Users :: ShowView < Proscenium :: Phlex
def 
