Quem opera model-driven apps em escala cedo ou tarde chega ao limite do que a configuração declarativa oferece. Business rules resolvem validações simples, colunas calculadas cobrem parte da lógica, mas há requisitos de interface — um mapa embutido, um seletor customizado, um cálculo em tempo real na tela — que exigem código no formulário. As duas ferramentas para isso são o PCF (PowerApps Component Framework) e o client scripting em JavaScript sobre o Client API. Elas não competem: resolvem problemas diferentes, e escolher errado gera dívida técnica cara.
\nO que cada abordagem realmente faz
\nO client scripting em JavaScript roda no contexto do formulário e reage a eventos: OnLoad, OnSave, OnChange de coluna, OnLookupTagClick. Você usa a formContext para ler e escrever atributos, mostrar/ocultar seções, disparar notificações e chamar a Web API. É a ferramenta certa para comportamento — orquestrar o formulário, validar antes de salvar, popular campos dependentes.
O PCF é outra categoria: você substitui a renderização de um controle (uma coluna ou até um grid inteiro) por um componente próprio em TypeScript/React. É a ferramenta certa para apresentação — quando o controle nativo não existe ou não atende, e você precisa de um slider, um card visual, um input mascarado, um mapa. O PCF recebe o valor via context.parameters e devolve mudanças pelo notifyOutputChanged, mantendo o dado no Dataverse como fonte da verdade.
Quando NÃO escrever código
\nAntes de abrir o VS Code, confirme que o requisito não cabe em configuração:
\nCódigo só se justifica quando o no-code não alcança. Cada linha de JavaScript ou componente PCF é algo que alguém vai ter que manter, testar em cada release e revalidar quando a Microsoft mexer no client.
\nBoas práticas de client scripting que evitam dor
\nXrm.Page — está deprecado. Receba executionContext no handler e obtenha a formContext a partir dele.PreventDefault e ressalve após a resposta — bloquear o save de forma síncrona degrada a experiência.setFormNotification).PCF e o custo de ALM que ninguém conta
\nO PCF é poderoso, mas tem custo operacional real:
\npac pcf, empacotamento e deploy pela pipeline, não upload manual.Na prática: PCF para poucos controles de alto valor, bem versionados, e não como resposta padrão para toda customização de tela.
\nRoteiro de decisão rápido
\nEssa última linha é o erro mais comum que vemos: colocar regra crítica de negócio em JavaScript de formulário. Se o dado pode entrar por integração, importação ou outro app, o client script simplesmente não roda — a regra tem que estar no servidor.
\nExtensão de model-driven apps é onde arquitetura e governança de ALM se encontram: escolher entre no-code, client script, PCF e plugin define o custo de manutenção dos próximos anos. Se sua equipe está avaliando até onde ir com código na Power Platform, a Dynamic Soluções ajuda a definir a arquitetura, estruturar o ALM em soluções gerenciadas e sustentar o ambiente com nossos planos de suporte.
\nAnyone running model-driven apps at scale eventually hits the ceiling of what declarative configuration offers. Business rules handle simple validations, calculated columns cover part of the logic, but there are UI requirements — an embedded map, a custom picker, a real-time on-screen calculation — that require code on the form. The two tools for this are the PCF (PowerApps Component Framework) and client scripting in JavaScript over the Client API. They don't compete: they solve different problems, and picking the wrong one creates expensive technical debt.
\nWhat each approach actually does
\nJavaScript client scripting runs in the form context and reacts to events: OnLoad, OnSave, OnChange of a column, OnLookupTagClick. You use formContext to read and write attributes, show/hide sections, raise notifications and call the Web API. It's the right tool for behavior — orchestrating the form, validating before save, populating dependent fields.
PCF is a different category: you replace the rendering of a control (a column or even an entire grid) with your own component in TypeScript/React. It's the right tool for presentation — when the native control doesn't exist or doesn't fit, and you need a slider, a visual card, a masked input, a map. PCF receives the value via context.parameters and pushes changes back through notifyOutputChanged, keeping the data in Dataverse as the source of truth.
When NOT to write code
\nBefore opening VS Code, confirm the requirement doesn't fit in configuration:
\nCode is only justified when no-code can't reach. Every line of JavaScript or PCF component is something someone will have to maintain, test on each release and revalidate whenever Microsoft changes the client.
\nClient scripting best practices that avoid pain
\nXrm.Page — it's deprecated. Receive executionContext in the handler and get formContext from it.PreventDefault and re-save after the response — blocking the save synchronously degrades the experience.setFormNotification).PCF and the ALM cost nobody counts
\nPCF is powerful, but it carries real operational cost:
\npac pcf, packaging and deploy through the pipeline, not manual upload.In practice: PCF for a few high-value, well-versioned controls, not as the default answer for every screen customization.
\nQuick decision guide
\nThat last line is the most common mistake we see: putting critical business rules in form JavaScript. If data can come in via integration, import or another app, the client script simply doesn't run — the rule has to be on the server.
\nExtending model-driven apps is where architecture and ALM governance meet: choosing between no-code, client script, PCF and plugin defines your maintenance cost for years to come. If your team is weighing how far to go with code on the Power Platform, Dynamic Soluções helps define the architecture, structure ALM in managed solutions and sustain the environment through our support plans.
"}},"pageContext":{"slug":"/blog/model-driven-form-pcf-javascript-client-scripting/","previousPost":null,"nextPost":{"frontmatter":{"title":"Power Pages: performance e SEO de portais externos na prática"},"fields":{"slug":"/blog/power-pages-performance-seo-portais-externos/"}}}},"staticQueryHashes":["2269431855"]}