Todas as coleções

Criando e copiando entidades

Buildprint materializa uma ramificação do Bubble como uma árvore de sistema de arquivos fragmentada que você edita como código. Em vez de escrever manualmente o JSON para uma nova página, tipo de dado ou workflow, use buildprint new para gerar uma base válida, buildprint copy para duplicar algo que já existe e buildprint components para empacotar ou instalar bundles de componentes reutilizáveis (os componentes têm sua própria documentação dedicada).

Execute estes comandos de dentro de um workspace de ramificação clonada (<app-root>/<branch>/). Cada scaffold e cópia grava arquivos somente nesse workspace. Nada é enviado ao Bubble até você executar apply.

Os scaffolds são um ponto de partida, não o resultado final. Depois que um comando é executado, ele imprime os arquivos que criou e lembra você de inspecioná-los e refiná-los. Quando terminar, valide o workspace com buildprint check e envie o resultado com buildprint apply.

Criando entidades com buildprint new

buildprint new agrupa um comando de scaffold por tipo de entidade. Execute buildprint new --help para listar todos eles.

Páginas, visualizações mobile e reusables

Páginas, visualizações mobile e reusables são raízes de canvas. Cada uma compartilha um --layout opcional (um de column, row ou fixed) e um --copy opcional para clonar uma raiz existente por id ou nome. --layout não pode ser combinado com --copy.

buildprint new page --name "Dashboard"
buildprint new page --name "Dashboard Copy" --copy "Dashboard"
buildprint new mobile --name "Home"
buildprint new mobile --name "Home Copy" --copy "Home"
buildprint new reusable --name "Sidebar"
buildprint new reusable --name "Create Modal" --element-type Popup
buildprint new mobile_reusable --name "Bottom Tab Shell"
buildprint new mobile_reusable --name "Account Sheet" --element-type Sheet

  • --name <name> é obrigatório para todas as quatro.

  • reusable e mobile_reusable também aceitam --element-type <type> (por exemplo Group ou Popup; o padrão é Group).

A opção --copy nesses comandos é a mesma operação que buildprint copy root; veja Copiando entidades abaixo.

Tipos de dado

buildprint new data_type --name "Project"
buildprint new data_type --name "Invoice" --field total:number --field owner:user
buildprint new data_type --name "Project API" --exposed-api --field status:option.project_status

  • --name <name> (obrigatório) define o nome de exibição.

  • --field <display:value> adiciona um campo no formato display:value (por exemplo title:text ou owner:user). Repita a flag para adicionar mais de um campo.

  • --exposed-api marca o tipo de dado como exposto pela Data API.

Conjuntos de opções

buildprint new option_set --name "Project Status"
buildprint new option_set --name "Project Status" --value Open --value Closed
buildprint new option_set --name "Project Status" --value "In Progress:in_progress"
buildprint new option_set --name "Evidence Strength" --value High --value Moderate --attribute color:text --attribute threshold:number

  • --name <name> (obrigatório) define o nome de exibição.

  • --value <value> adiciona uma opção. Passe um rótulo de exibição simples como Open para derivar automaticamente o db_value, ou Display:db_value (por exemplo In Progress:in_progress) para definir ambos explicitamente. Repita para adicionar mais opções.

  • --attribute <display:value> adiciona um atributo de opção no formato display:value (por exemplo color:text ou threshold:number). Repita para adicionar mais.

Expressões globais

buildprint new global-expression --name "Current User"

  • --name <name> é obrigatório.

Workflows

buildprint new workflow gera um scaffold de workflow sob um proprietário de workflow existente (o diretório workflows de uma página ou a raiz api) e, opcionalmente, uma pasta dentro dele.

buildprint new workflow --path api --name "Use Tool" --type CustomEvent
buildprint new workflow --path api --folder "Tools" --name "Use Tool" --type CustomEvent --param toolCallName:text --param toolCallArguments:text --actions 2
buildprint new workflow --path api --name "Find User" --type CustomEvent --param email:text --returnParam user:user --actions 1
buildprint new workflow --path api --folder "Queue" --name "Queue Work" --type APIEvent --param "users:user[]?"
buildprint new workflow --path pages/home/workflows --name "Page Loaded" --type PageLoaded
buildprint new workflow --path pages/home/workflows/modals --name "Open Modal" --type ConditionTrue

  • --path <path> (obrigatório) é a raiz do proprietário do workflow ou o caminho de uma pasta de workflow existente. Se já apontar para uma pasta, essa pasta é inferida como destino.

  • --name <name> (obrigatório) é o nome do workflow.

  • --type <type> (obrigatório) é o tipo de evento do workflow, como APIEvent, CustomEvent, ButtonClicked ou ConditionTrue.

  • --folder <folder> coloca o workflow em uma pasta por chave bruta ou nome de exibição. Se for omitido e --path já apontar para uma pasta, essa pasta será usada.

  • --param <name:type> adiciona um parâmetro. Os nomes aceitam os sufixos opcionais [] (lista) e ? (opcional); entre aspas as especificações que contiverem [] ou ? em shells como zsh. Repita para adicionar mais.

  • --returnParam <name:type> adiciona um valor de retorno, usando o mesmo formato name:type. Suportado para workflows APIEvent e CustomEvent.

  • --actions <count> cria essa quantidade de arquivos de ação placeholder.

Ações

buildprint new action adiciona uma ação a um workflow existente. Por padrão, a ação é acrescentada como o último passo; use --after ou --before para inserir em uma posição específica.

buildprint new action --path api/my-workflow --type TriggerCustomEvent
buildprint new action --path api/tools/my-workflow --type ScheduleAPIEvent --name "Schedule audit event"
buildprint new action --path pages/home/workflows/load-page --after 1 --type HideElement
buildprint new action --path pages/home/workflows/modals/open-popup/workflow.json --before bpAction123 --type ShowElement

  • --path <path> (obrigatório) é um diretório de workflow existente ou um caminho workflow.json.

  • --type <type> (obrigatório) é o tipo de ação, como ChangeThing ou TriggerCustomEvent.

  • --name <name> define um nome opcional para a ação.

  • --after <step-or-id> insere depois de um número de passo baseado em um existente ou do id de uma ação.

  • --before <step-or-id> insere antes de um número de passo baseado em um existente ou do id de uma ação.

--after e --before não podem ser usados juntos. A inserção é rejeitada quando um passo posterior contém uma referência posicional ao passo anterior que a reorganização quebraria; o erro lista os arquivos afetados para que você possa acrescentar em vez disso.

Pastas de workflow

buildprint new folder --path api --name "Tools"
buildprint new folder --path pages/home/workflows --name "Modals"

  • --path <path> (obrigatório) é a raiz do proprietário do workflow, como api ou pages/<page>/workflows. Passe a raiz do proprietário, não uma pasta que já exista.

  • --name <name> (obrigatório) é o nome de exibição da pasta.

Testes locais

buildprint new test e buildprint new test-step geram definições de testes locais e acrescentam passos a elas.

buildprint new test --name "Checkout"
buildprint new test --name "Checkout" --folder smoke
buildprint new test --component --name "Login"
buildprint new test-step --path tests/smoke/checkout.json --type test --instruction "Open checkout"
buildprint new test-step --path tests/smoke/checkout.json --type component --component login

buildprint new test:

  • --name <name> (obrigatório) é o nome de exibição do teste ou do componente.

  • --folder <key-or-name> agrupa o teste em uma pasta.

  • --component cria um componente de teste reutilizável em vez de um teste.

buildprint new test-step:

  • --path <path> (obrigatório) é o caminho JSON do teste, como tests/smoke/checkout.json.

  • --type <type> (obrigatório) é test, condition ou component.

  • --component <key> é a chave estável do componente, obrigatória para passos component.

  • --parent <key> é a chave do nó pai no grafo (o padrão é o passo anterior ou o nó inicial).

  • --condition <outcome> é o resultado do pai da condição, met ou not_met.

  • --instruction <text>, --details <text> e --tips <text> preenchem o texto para passos test e condition.

  • --on-failure <mode> é o comportamento em caso de falha, stop ou continue (padrão stop).

Workspaces de plugin

Os projetos de plugin têm seus próprios scaffolds em buildprint new plugin <command> (por exemplo buildprint new plugin element, buildprint new plugin action e buildprint new plugin api-call). Execute buildprint new plugin --help para listá-los. A criação de plugins é abordada em sua própria página.

Copiando entidades com buildprint copy

buildprint copy duplica raízes, workflows, ações ou subárvores de elementos existentes. Cada cópia cria novos ids, de modo que a nova entidade é independente da origem (veja Como os ids são reescritos).

buildprint copy root --kind page --source "Marketing Home" --name "Marketing Home Copy"
buildprint copy workflow --source api/tools/use-tool --path api --folder "Backups" --name "Use Tool Copy"
buildprint copy element --source pages/home/elements/sidebar --path pages/home
buildprint copy action --from api/tools/use-tool --source 0 --path pages/home/workflows/load-page --after 1

copy root

Copia uma página, visualização mobile ou reusable para uma nova raiz.

  • --kind <kind> (obrigatório) é o tipo de destino: page, mobile, reusable ou mobile_reusable.

  • --source <source> (obrigatório) é o id da raiz de origem, a chave bruta ou o nome de exibição.

  • --name <name> (obrigatório) é o nome da nova raiz.

  • --element-type <type> substitui o tipo de elemento para destinos reusable.

copy workflow

Copia um workflow existente para outro proprietário de workflow ou pasta.

  • --source <path> (obrigatório) é o diretório de workflow existente ou o caminho workflow.json.

  • --path <path> (obrigatório) é a raiz do proprietário do workflow de destino ou o caminho da pasta de workflow.

  • --folder <folder> é a chave bruta ou o nome de exibição da pasta de destino.

  • --name <name> substitui o nome do workflow copiado.

copy element

Copia uma subárvore de elemento sob uma raiz de canvas ou outro elemento.

  • --source <path> (obrigatório) é o diretório de elemento existente ou o caminho element.json.

  • --path <path> (obrigatório) é a raiz de canvas de destino ou o caminho do elemento pai.

copy action

Copia uma ou mais ações de um workflow para outro.

  • --from <path> (obrigatório) é o diretório de workflow de origem ou o caminho workflow.json.

  • --path <path> (obrigatório) é o diretório de workflow de destino ou o caminho workflow.json.

  • --source <step-or-id> seleciona uma ação de origem por número de passo baseado em um existente ou por id de ação. Repita a flag para copiar várias ações.

  • --name <name> substitui o nome da ação copiada e só é permitido ao copiar exatamente uma ação.

  • --after <step-or-id> insere depois de um passo de destino existente ou do id de uma ação.

  • --before <step-or-id> insere antes de um passo de destino existente ou do id de uma ação.

--after e --before não podem ser usados juntos. Assim como em new action, uma inserção é rejeitada quando ela reordenaria passos posteriores que mantêm referências posicionais ao passo anterior. Copiar uma ação cuja referência PreviousStep aponta para fora do conjunto copiado também é rejeitado; portanto, copie toda a cadeia dependente ou remova primeiro a dependência posicional.

Depois de criar ou copiar

Cada comando new e copy grava arquivos de base no workspace e para por aí. Inspecione o que foi criado, complete quaisquer campos deixados como placeholders e então:

  1. Execute buildprint check para validar o workspace. O check é direcionado às entidades que você modificou, então é nele que campos obrigatórios e outros problemas aparecem.

  2. Execute buildprint apply para compilar o diff em gravações no Bubble e enviá-lo para sua branch.

Isso foi útil?