Práticas recomendadas de script de cliente

Embora o desenvolvimento de scripts de cliente possa parecer simples para desenvolvedores JavaScript experientes, é essencial seguir as práticas recomendadas ao implementá-los. Os desenvolvedores muitas vezes ignoram que os usuários podem acessar os dados por outros meios. Por exemplo, eles podem usar importação ou exportação de dados, estúdio do criador, aplicativos de tela, aplicativos da área de trabalho de terceiros, scripts de shell etc. Você deve usar scripts de cliente para resolver problemas específicos de IU do lado do cliente e aprimorar a experiência do usuário em um aplicativo baseado em modelo. Não é uma medida de segurança nem uma solução universal. Frequentemente, uma abordagem no lado do cliente deve ser combinada com uma solução no servidor, como um plug-in do Dataverse, para garantir que todos os pontos de acesso atendam aos requisitos de negócios.

Usar o verificador de solução

O Verificador de Solução pode realizar verificações de análise estática em suas soluções em relação a um conjunto de regras de práticas recomendadas e identificar rapidamente esses padrões problemáticos. Essa verificação inclui o JavaScript usado para script de cliente. O verificador pode identificar problemas de desempenho, estabilidade e confiabilidade à medida que ocorrem, o que pode prejudicar a experiência do usuário. O verificador também pode identificar o uso de métodos preteridos. Ao executá-lo regularmente, você pode identificar e corrigir os problemas de forma proativa, antes que ocorram para os usuários. Você pode executar o Verificador de Solução sob demanda no Maker Portal ou como parte de um processo de criação automatizado. Essa automação permite que ele seja executado regularmente e passe a fazer parte do seu processo contínuo de gerenciamento do ciclo de vida do aplicativo.

Para obter mais informações sobre como usar o Verificador de Solução, consulte Usar o Verificador de Solução para validar seus aplicativos no Power Apps na documentação do produto.

Regras de negócios versus script de cliente

Regras de negócios são um recurso disponível em aplicativos baseados em modelo que permitem que os usuários executem ações frequentemente necessárias em um formulário com base em determinados requisitos e condições. Especificamente, as regras de negócios podem realizar as seguintes tarefas:

• Definir valores de campo

• Limpar valores de campo

• Definir níveis de requisitos do campo

• Mostrar ou ocultar controles de coluna do formulário

• Habilitar ou desabilitar controles de coluna do formulário

• Validar dados e mostrar mensagens de erro

• Criar recomendações de negócios com base em business intelligence.

Um dos recursos distintos das regras de negócios é que as regras com escopo de tabela podem aplicar automaticamente a lógica ao back-end quando apropriado. Esse escopo garante a consistência do aplicativo, independentemente de uma ação ser executada por meio da interface do usuário, da importação de dados ou de uma chamada de método de API. O script de cliente sozinho não é um equivalente completo nesses cenários.

Embora a estrutura disponível de regras de negócios seja robusta, podem existir alguns cenários em que essas regras não possam implementar totalmente determinado requisito. Nesses casos, o script de cliente pode reduzir as diferenças entre as regras de negócios e um requisito mais exigente. Aqui estão algumas limitações comuns que os usuários enfrentam com as regras de negócios, quando o script de cliente pode ser uma solução melhor.

Dados relacionados de referência

Se precisar fazer referência a dados em uma tabela relacionada, como o endereço do contato principal de uma conta, você precisará usar o script do cliente e a API Web.

A lógica precisa ser executada no evento de salvamento do formulário

As regras de negócios são executadas apenas no carregamento do formulário e na alteração de um campo, a menos que você defina o escopo como tabela. Você deverá usar um script de cliente se precisar que a lógica de negócios seja executada no evento Salvar formulário.

Condições complexas

Se sua condição tiver várias instruções and ou precisar de instruções or, escrever essas condições no script do cliente poderá ser mais eficiente do que por meio de regras de negócios.

Limpar valores dos dados do formulário

A limpeza de dados de uma coluna de formulário não é realizada facilmente em uma regra de negócios. Embora existam soluções alternativas que você pode usar, como atribuir uma coluna "fictícia" que sempre contém valores NULL, você pode fazer isso de maneira mais elegante usando o script do cliente.

Colunas calculadas versus script de cliente

As colunas calculadas executam a lógica na recuperação; portanto, quaisquer alterações do lado do cliente não refletem no valor da coluna calculada até que um formulário seja atualizado. Se você deseja que os dados sejam atualizados instantaneamente no formulário, o script de cliente é o método preferencial. Frequentemente, o script do cliente complementa uma implementação de back-end que usa colunas calculadas ou cumulativas, plug-ins etc. Essa abordagem combinada pode fornecer uma experiência de usuário consistente no aplicativo, ao mesmo tempo que garante a consistência e integridade dos dados no back-end.

Padrões de codificação e práticas recomendadas

As seções a seguir abordam as práticas recomendadas e os padrões de codificação.

Definir nomes de função de script exclusivos

As funções que você escreve provavelmente estão em um formulário com muitas outras bibliotecas. Se outra biblioteca contiver uma função com o mesmo nome daquela que você forneceu, a função que for carregada por último será aquela que o formulário usará. Para evitar um conflito potencial, use nomes de função exclusivos. Você poderá usar as seguintes estratégias se você ou sua organização ainda não tiver uma estratégia estabelecida:

• Prefixo de função exclusivo: defina cada um das funções usando a sintaxe padrão com um nome consistente que inclua uma convenção de nomenclatura exclusiva, como mostra o exemplo a seguir.

    function MyUniqueName_performMyAction()
    {
    // Code to perform your action.
    }
  

• Bibliotecas com namespaces: associe cada função a um objeto de script para criar um namespace a ser usado quando você chamar as funções, como mostra o exemplo a seguir.

    //If the MyUniqueName namespace object isn’t defined, create it.
    if (typeof (MyUniqueName) == "undefined")
       { MyUniqueName = {}; }
       // Create Namespace container for functions in this library;
       MyUniqueName.MyFunctions = {
     performMyAction: function(){
     // Code to perform your action.
     //Call another function in your library
     this.anotherAction();
       },
       anotherAction: function(){
     // Code in another function
      }
    };
  

Ao usar a função, especifique o nome completo, como mostra o exemplo a seguir.

    MyUniqueName.MyFunctions.performMyAction();

Evitar métodos sem suporte

Embora alguns recursos online de terceiros possam sugerir ou ter exemplos de como você pode usar métodos sem suporte para executar determinadas ações, isso não tem suporte nem é recomendado. Não é possível garantir que esses métodos funcionem em versões futuras do aplicativo, e eles podem contribuir para a instabilidade da sua implementação. Você também deverá evitar métodos descobertos inspecionando os objetos da API no depurador se os métodos descobertos não estiverem na documentação oficial da documentação de referência da API do cliente.

Verificar se há métodos preteridos no código

A API de cliente está sendo desenvolvida e aprimorada continuamente. É importante examinar sua base de código quanto ao uso de métodos preteridos e seguir as recomendações da documentação para suas substituições. Se você usar o Verificador de Solução, ele sinalizará esses métodos como problemas.

Evitar o uso da jQuery em formulários e comandos da faixa de opções

jQuery e outras bibliotecas de manipulação direta de HTML DOM não têm suporte em scripts de formulário ou comandos da barra de comandos. Você deve restringir seus scripts apenas ao uso de métodos no modelo de objeto da API do Cliente. Para obter mais informações, consulte Compreender o modelo de objeto da API do Cliente.

Escrever código que não cause bloqueio

Você deve usar padrões assíncronos para garantir uma experiência de usuário sem bloqueio ao realizar consultas ou atividades com uso intensivo de processos.

Tente evitar métodos que bloqueiem a IU, como caixas de diálogo de confirmação, bloqueio de indicadores de progresso etc. O método preferido de interação com o usuário é por meio de mecanismos de notificação não intrusivos, como uma área de alerta altamente visível no aplicativo ou formulário.

Escrever código para vários navegadores

Verifique se todos os scripts implementados foram testados para funcionar em todos os navegadores e formatos de dispositivos que os usuários usam com seus aplicativos baseados em modelo. Para obter mais informações, veja Navegadores da Web e dispositivos móveis com suporte.