Aloha amigos, tudo na paz?

O post de hoje será útil para quem deseja limitar o uso de memória RAM da nossa aplicação rodando com Docker.

Por que limitar o uso de memória RAM?

Ao utilizar o Docker no Linux, percebi que o mesmo utiliza uma quantidade considerável de memória RAM.

O mesmo já não acontece nos computadores da Apple, pois como ele utiliza o Docker for Mac, é possível limitar a quantidade de memória RAM à ser utilizada.

Para verificar quanto de memória RAM o seu serviço está utilizando, basta subir o contêiner, e em seguida, executar no terminal o seguinte comando:

Por essa tela podemos observar a quantidade de memória RAM que o nosso serviço está utilizando, através da coluna MEM USAGE, e qual o limite que ele poderá utilizar (coluna LIMIT).

O meu notebook possui 16GB de RAM, e a coluna LIMIT mostra que o serviço pode utilizar praticamente 16GB. Ou seja, ele pode utilizar toda a memória RAM, ocasionando assim num eventual travamento da máquina (o que já aconteceu algumas vezes).

Limites/Reservas de memória

Para entender limites de memória e reservas de memória de uma maneira bem resumida:

• Limite de memória: um limite superior estrito à quantidade de memória disponibilizada para um contêiner.
• Reserva de memória: deve ser definida como a quantidade mínima de memória necessária para que um aplicativo seja executado corretamente. Portanto, não falha ou se comporta mal quando o sistema está tentando recuperar parte da memória.

Especificando limites/reserva de memória na versão 3.7

Se você utiliza a versão 3.7 do docker-compose, deve-se inserir a seguinte configuração no arquivo docker-compose.yml:

Com isso, estamos dizendo ao docker que ele pode utilizar no máximo 4GB de RAM, com uma reserva mínima de 2GB.

Feito isso, basta salvar e subir nossa aplicação novamente, com o comando:

Ao subir a aplicação, nos deparamos com a seguinte mensagem de alerta:

WARNING: Some services (web) use the ‘deploy’ key, which will be ignored. Compose does not support ‘deploy’ configuration — use `docker stack deploy` to deploy to a swarm.

Essa mensagem é exibida porquê o docker-compose na versão 3.x não suporta a chave de deploy. Para que isso funcione corretamente, deve-se executar o docker no modo swarm.

- - Compatibility

Porém, uma maneira mais simples que encontrei de resolver essa questão, foi subir a aplicação docker com a flag compatibility:

Segundo a documentação:

If set, Compose will attempt to convert deploy keys in v3 files to their non-Swarm equivalent

Ou seja, o docker-compose tentará converter as chaves de deploy nos arquivos v3 em seus equivalentes não Swarm.

Após isso, basta executar o seguinte comando no terminal para ver se a configuração funcionou:

Com isso, podemos observar agora que o limite de memória RAM do nosso serviço é 4GB.

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral, deixem um comentário, pois estamos sempre monitorando. Mahalo!

Quer fazer sugestões ou tirar dúvidas? Entre em contato com a gente \o/ Obrigada por ler!

ASSINE NOSSA NEWSLETTER!
E fique por dentro de tudo o que acontece no Ateliê.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Nosso site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Limitando o uso de memória RAM no docker-compose was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aloha amigos, tudo na paz?

Vocês alguma vez já estiveram em um website, preencheram aquele formulário gigantesco, e por algum motivo atualizaram a página acidentalmente ou saíram sem salvar, perdendo todo o trabalho realizado?

Pensando na experiência do usuário (UX), isso é terrível, podendo fazer com que ele nunca mais retorne ao seu website.

Para amenizar esse problema, podemos criar de forma simples, um JavaScript que alerte o nosso usuário caso o mesmo tente sair do formulário sem salvar as alterações realizadas.

Formulário

Para começar, iremos utilizar como exemplo um formulário simples para cadastrar usuários:

JavaScript (jQuery)

Para verificarmos as alterações não salvas no formulário, deve-se utilizar um pouco de JavaScript. Vamos criar um arquivo chamado form_check_modified.js, com o seguinte trecho de código:

Estamos selecionando o formulário por meio de uma role ([role=“check-modified”]), o que significa que precisaremos modificar o formulário de usuário para incluir essa função.

Essa é uma boa prática utilizada para prevenir alertas indesejados na aplicação, como formulários de pesquisa ou outros que serão salvos automaticamente quando os campos forem alterados.

Então, no formulário de usuário, vamos adicionar a role “check-modified”, para que o JavaScript possa verificar nosso formulário quanto às alterações não salvas:

<%= simple_form_for(@user, html: { role: ‘check-modified’ }) do |f| %>

Resultado

Agora, quando atualizamos nossa página, sempre que modificamos o formulário e tentamos sair sem salvar, recebemos o seguinte alerta:

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral, deixem um comentário, pois estamos sempre monitorando. Mahalo!

Quer fazer sugestões ou tirar dúvidas? Entre em contato com a gente \o/ Obrigada por ler!

ASSINE NOSSA NEWSLETTER!
E fique por dentro de tudo o que acontece no Ateliê.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Nosso site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Alertando o usuário sobre alterações não salvas no formulário was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Essa dica serve para Ruby on Rails, utilizando Docker e a gem BetterErrors

Aloha amigos, tudo na paz?

Podemos utilizar a gem BetterErrors para exibirmos uma página de erro mais amigável no Rails. Em conjunto, utilizamos ainda outra gem, a binding_of_caller, permitindo debugar nossa aplicação pelo próprio navegador.

Para que isso funcione corretamente, precisamos informar ao BetterErrors qual o ip da nossa aplicação, através da configuração. Segue abaixo um exemplo:

BetterErrors::Middleware.allow_ip! “172.18.0.1”

Com isso, teremos uma tela de erro exibida dessa forma:

Docker

Utilizamos o docker para subir nossas aplicações. Porém, o que ocorre em muitas das vezes é que o docker utiliza ip diferente ao subir um servidor, e com isso, nossa configuração do BetterErrors deixa de funcionar.

Configurando o BetterErrors

Para corrigirmos isso, vamos criar um arquivo better_errors.rb na pasta config/initializers. Nesse arquivo, iremos inserir a seguinte configuração:

Feito isso, basta subir o servidor novamente.

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral, deixem um comentário, pois estamos sempre monitorando. Mahalo!

ASSINE NOSSA NEWSLETTER! E dê um alô pra gente, nos acompanhe nas redes sociais: → Site → Facebook → Instagram → Twitter → Youtube

Ajuste do BetterErrors (ip dinâmico) para Docker was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aloha amigos, tudo na paz?

Aqui no Ateliê de Software utilizamos o TDD (Test Driven Development), ou Desenvolvimento Orientado por Testes, que consiste basicamente em:

Escreva seus testes antes mesmo de escrever o código de produção

Essa prática ajuda a prevenir erros que poderiam surgir com a introdução de novos requisitos, além de manter a qualidade do nosso código.

Para desenvolver nossos testes, utilizamos RSpec, Factory Bot e FFaker.

Duplicidade na geração de dados das factories (FFaker)

Utilizamos o RSpec para escrever nossos testes, aliado ao Factory Bot para geração das factories, além do FFaker, para geração de dados aleatórios.

Acontece que, se nossa aplicação possuir muitos testes, o FFaker pode começar a gerar dados repetidos (o que não deveria, já que os mesmos são aleatórios).

Para isso, podemos utilizar uma configuração que resolve essa questão.

Configurando nosso projeto

Devemos configurar a nossa estrutura para que os testes sejam executados em transações. No arquivo spec/rails_helper.rb, insira a seguinte linha de código:

Vamos agora realizar a configuração das factories. Temos como exemplo uma factory de usuário:

Vamos envolver os atributos em blocos. Isso ajuda o FFaker a manter a singularidade do dados. Segue abaixo como nossa factory ficará:

E por fim, pode-se acrescentar ao FFaker o método unique, garantindo que o dado gerado seja único. A versão final de nossa factory ficará assim:

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral, deixem um comentário, pois estamos sempre monitorando. Mahalo!

ASSINE NOSSA NEWSLETTER!
E fique por dentro de tudo o que acontece no Ateliê.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Nosso site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Evitando erros de duplicidade com Factory Bot was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aloha amigos, tudo na paz?

O post de hoje será útil para quem deseja criar, em poucos passos, um Toggle Switch Button (ou botão de On/Off).

Em formulários nos quais o usuário precisa responder com Sim ou Não, geralmente fazemos uso dos famosos checkboxes ou radios buttons. Porém a UX não fica tão legal, já que esses recursos não possuem uma usabilidade tão intuitiva.

Com base nisso, podemos utilizar um Toggle Switch, que são amplamente utilizados em smartphones, além de possuírem um visual legal e serem bem mais indicativos. Então mãos à obra!

HTML

Para criar um checkbox em HTML, podemos utilizar a seguinte instrução:

E o resultado gerado será este:

CSS

Para conseguirmos atingir o nosso objetivo, foi necessário criar um arquivo Sass para customizar o nosso checkbox. Segue o código:

Após criar o CSS acima, devemos alterar nosso HTML, inserindo uma classe switch no nosso checkbox. O código ficará assim:

Com isso, obtemos o seguinte resultado:

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral, deixem um comentário, pois estamos sempre monitorando. Mahalo!

ASSINE NOSSA NEWSLETTER!
E fique por dentro de tudo o que acontece no Ateliê.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Nosso site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Criando um Toggle Switch Button com Sass was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aloha friends, everything’s fine?
In today’s post we’ll create an OAuth provider, which aims to act as an authorization server, allowing multiple applications (clients) to log in to a single location. And for that we’ll use the Doorkeeper and Devise libraries.

First of all, I’d like to thank the help of my co-workers Jorge David and Altieres Ribeiro Lopes in the preparation of this project, and Gustavo Canedo who has helped with various issues concerning Docker.

OAuth

First we need to know what OAuth is.

OAuth is a widely used authorization protocol for scalable web applications. The current version is 2.0, which makes use of tokens to access data on another system, and probably in another database.

Have you ever stopped to think about how access is made to your Facebook account in mobile games? It’s with OAuth!

This protocol enables other systems to access some data without you always having to log in, returning authorization tokens.

For more information, access the official documentation through this link.

The app

Let’s now explain how our application will work. It’ll be divided into two parts: the authorization server, which we’ll call Accounts, and the client, which will be our Client.

Both Accounts and Client will have authentication (with email and password), which will be created by Devise. The access data will be these:

Accounts

E-mail: accounts@ateliedesoftware.com.br
Password: 123456

Client:

E-mail: client@ateliedesoftware.com.br
Password: 123456

Let’s go to the business rules:

Scenario 1: Accounts unlogged and Client unlogged

When the Client tries to log into Accounts, the Accounts login screen will appear, and after entering the access data, the user will be redirected to the Client.

Result: Accounts logged in and Client logged in

Scenario 2: Accounts logged in and Client unlogged

When the Client attempts to log into Accounts, the user will be redirected to the Client, without having to enter the access data.

Result: Accounts logged in and Client logged in

Scenario 3: Accounts unlogged and Client unlogged

When the Client attempts to log in locally, the Client login screen will be displayed, and after entering the access data, the user will be redirected to the Client itself.

Result: Accounts unlogged and Client logged in

Creating the authorization server (Accounts)

For the authorization server, we’ll create an application in Ruby on Rails and use the following gems:

Run the installation with the following command on the terminal:

This will generate the Doorkeeper initializer in config/initializers/doorkeeper.rb

After that, we should generate the Doorkeeper migration, using the following command:

And finally, we added foreign keys to our migration. Our file will look like this:

Configuration

After running the migration, with the rails db:migrate command, we’ll leave our user model as follows:

Routes

Our routes will look like this:

Authentication

We now need to configure our doorkeeper.rb file. In this step we will perform 3 configurations:

• resource_owner_authenticator: configuration to perform Doorkeeper integration with Devise. It’ll be responsible for redirecting the user to your application after login (see scenario 1 of our business rules).
• force_ssl_in_redirect_uri: configuration to determine if we will use https or http. In our case, it will be false.
• skip_authorization: A setting that defines whether the authorization form is displayed to the user. In our application, the authentication must be transparent to the user, that is, an authorization confirmation screen should not appear. This will be set to true.

Following the settings above, our doorkeeper.rb file should look like this:

And to finish the configuration of the authorization server, we’ll create the following controllers that should be in the path controllers/api/v1:

Creating the access provider (Client)

For the access provider, we’ll create an application in Ruby on Rails and use the following gems:

We should now create a migration to add the provider and uid fields to the users model. Our file will look like this:

OmniAuth

OmniAuth assumes that the authorization process has two main phases: request and call-back:

• Request is the step where the provider is called. This provider authenticates the user and requests the user’s permission to share the data in the application.
• The provider then performs the callback with the required information.

OmniAuth Strategy

OmniAuth lets you add custom providers. For this, we must create a login scheme for our provider through a strategy. Our strategy will be called Webgoal and will be located in lib/strategies/webgoal.rb. The following settings will be performed:

• option :name will contain the name of our strategy.
• option :client_options, { :site => … } will contain the URL of our authorization server (the one we created above).

With this, our webgoal.rb file will look like this:

Devise

Once the Webgoal strategy is created, we must inform it in our devise.rb file. With this, our file will conform to the code snippet below (detail for line 36):

When registering a strategy, we must inform the id (DOORKEEPER_APP_ID) and secret (DOORKEEPER_APP_SECRET) generated by Doorkeeper. To generate these fields, we must register our application in the Doorkeeper.

With the authorization server running, we will access the following address:

http://accounts:3001/oauth/applications

Click the New Application button and enter the following data:

Name: Client
Redirect URI: http://client:3002/users/auth/webgoal/callback
Scopes: leave blank

With this, the following screen will be displayed:

• The Application UID must be used in the Webgoal strategy instead of the DOORKEEPER_APP_ID.
• The Secret should be used in the Webgoal strategy instead of the DOORKEEPER_APP_SECRET.

After this step, we must create a controller in the users folder, called omniauth_callbacks_controller, which will be responsible for executing the callback triggered by the request of the provider:

And to finish, we must create a logout action, which will be responsible for performing the local and server logout. The code looks like this:

Project source code

This project is hosted on GitHub by Webgoal. To access it, just use the following links:

• Complete project
• Accounts
• Client

Project Images

Conclusion

That’s it for today, folks! I hope you enjoyed. Any questions, suggestions or feedback in general leave a comment, as we are always monitoring. Mahalo!

Want to make suggestions or ask questions? Contact us \o/
Thanks for reading!

SIGN UP FOR OUR NEWSLETTER!
And stay inside everything that happens in Ateliê.

Say hello to us! And join us on social networks:
→ Our site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Creating an OAuth Provider was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Aloha amigos, tudo na paz?
No post de hoje vamos criar um provedor OAuth, tendo por objetivo atuar como um servidor de autorização, possibilitando que múltiplas aplicações (clientes) possam realizar o login em um único local. E para isso vamos utilizar as bibliotecas Doorkeeper e Devise.

Antes de tudo, gostaria de agradecer a ajuda dos colegas de trabalho Jorge David e Altieres Ribeiro Lopes na elaboração deste projeto e do Gustavo Canedo que ajudou em diversas questões referentes ao Docker.

OAuth

Primeiramente precisamos saber o que é o OAuth.

O OAuth é um protocolo de autorização muito utilizado em aplicações web escaláveis. A versão atual é a 2.0, que faz uso de tokens para acessar dados em outro sistema, e provavelmente em outro banco de dados.

Você já parou para pensar como é feito o acesso à sua conta Facebook em jogos para celular? É utilizando OAuth!

Esse protocolo possibilita que outros sistemas acessem alguns dados sem que você precise fazer login sempre, retornando tokens de autorização.

Para mais informações, acesse a documentação oficial através desse link.

A aplicação

Vamos explicar agora como nossa aplicação irá funcionar. Ela será dividida em duas partes: o servidor de autorização, que chamaremos de Accounts, e o cliente, que será nosso Client.

Tanto o Accounts quanto o Client irão possuir autenticação (com e-mail e senha), que serão criados pela Devise. Os dados de acesso serão esses:

Accounts

E-mail: accounts@ateliedesoftware.com.br
Senha: 123456

Client:

E-mail: client@ateliedesoftware.com.br
Senha: 123456

Vamos para as regras de negócio:

Cenário 1: Accounts deslogado e Client deslogado

Quando o Client tentar logar no Accounts, será exibida a tela de login do Accounts e após a inserção dos dados de acesso, o usuário será redirecionado para o Client.

Resultado: Accounts logado e Client logado

Cenário 2: Accounts logado e Client deslogado

Quando o Client tentar logar no Accounts, o usuário será redirecionado para o Client, sem a necessidade de informar os dados de acesso.

Resultado: Accounts logado e Client logado

Cenário 3: Accounts deslogado e Client deslogado

Quando o Client tentar logar localmente, será exibida a tela de login do Client e após a inserção dos dados de acesso, o usuário será redirecionado para o próprio Client.

Resultado: Accounts deslogado e Client logado

Criando o servidor de autorização (Accounts)

Para o servidor de autorização, criaremos uma aplicação em Ruby on Rails e utilizaremos as seguintes gems:

Execute a instalação com o seguinte comando no terminal:

Isso irá gerar o inicializador do Doorkeeper em config/initializers/doorkeeper.rb

Após isso, deveremos gerar a migração do Doorkeeper, utilizando o seguinte comando:

E por fim, adicionamos chaves estrangeiras à nossa migração. O nosso arquivo ficará assim:

Configuração

Após executar a migração, com o comando rails db:migrate, iremos deixar a nossa model de usuário da seguinte forma:

Rotas

As nossas rotas ficarão assim:

Autenticação

Precisamos agora configurar o nosso arquivo doorkeeper.rb. Nessa etapa iremos realizar 3 configurações:

• resource_owner_authenticator: configuração para realizar a integração do Doorkeeper com a Devise. Será responsável por fazer o redirecionamento do usuário para sua aplicação após o login (vide cenário 1 das nossas regras de negócio).
• force_ssl_in_redirect_uri: configuração para determinar se iremos utilizar https ou http. No nosso caso, será false.
• skip_authorization: configuração que define se a tela de autorização será exibida para o usuário. Na nossa aplicação, a autenticação deve ser transparente para o usuário, ou seja, não deverá aparecer uma tela de confirmação de autorização. Com isso, será definida como true.

Realizada as configurações acima, o nosso arquivo doorkeeper.rb deverá ficar assim:

E para finalizar a configuração do servidor de autorização, iremos criar as seguintes controllers que deverão ficar no caminho controllers/api/v1:

Criando o provedor de acesso (Client)

Para o provedor de acesso, criaremos uma aplicação em Ruby on Rails e utilizaremos as seguintes gems:

Devemos agora criar uma migração para adicionar os campos provider e uid para a model de usuários. O nosso arquivo ficará assim:

OmniAuth

O OmniAuth assume que o processo de autorização possui duas fases principais: request e callback:

• Request é a etapa onde o provedor (provider) é chamado. Esse provedor autentica o usuário e pede a permissão do usuário para compartilhar os dados na aplicação.
• O provedor então executa o callback com as informações necessárias.

Estratégia OmniAuth

O OmniAuth permite adicionar provedores customizados. Para isso, devemos criar um esquema de login para o nosso provedor através de uma estratégia. A nossa estratégia vai se chamar Webgoal e ficará localizada em lib/strategies/webgoal.rb. As seguintes configurações serão realizadas:

• option :name irá conter o nome da nossa estratégia.
• option :client_options, { :site => … } irá conter a URL do nosso servidor de autorização (que criamos acima).

Com isso, o nosso arquivo webgoal.rb ficará assim:

Devise

Uma vez criada a estratégia Webgoal, devemos informá-la no nosso arquivo devise.rb. Com isso, nosso arquivo ficará conforme o trecho de código abaixo (detalhe para a linha 36):

Ao registrar uma estratégia, devemos informar os id (DOORKEEPER_APP_ID) e secret (DOORKEEPER_APP_SECRET) gerados pelo Doorkeeper. Para gerarmos esses campos, devemos registrar nossa aplicação no Doorkeeper.

Com o servidor de autorização rodando, vamos acessar o seguinte endereço:

http://accounts:3001/oauth/applications

Clicar no botão Nova Aplicação e inserir os seguintes dados:

Nome: Client
URI de redirecionamento: http://client:3002/users/auth/webgoal/callback
Scopes: deixar em branco

Com isso, a seguinte tela será exibida:

• O Id da Aplicação (Application UID) deve ser utilizado na estratégia Webgoal no lugar do DOORKEEPER_APP_ID.
• O Segredo (Secret) deve ser utilizado na estratégia Webgoal no lugar do DOORKEEPER_APP_SECRET.

Realizada essa etapa, devemos criar uma controller na pasta users, chamada omniauth_callbacks_controller, que será responsável por executar o callback disparado pela request do provedor:

E para encerrar, devemos criar uma action de logout, que será responsável por realizar o logout local e do servidor. O código fica assim:

Código-fonte do projeto

Este projeto está hospedado no GitHub da Webgoal. Para acessá-lo, basta utilizar os seguintes links:

• Projeto completo
• Accounts
• Client

Imagens do projeto

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral deixem um comentário, pois estamos sempre monitorando. Mahalo!

Quer fazer sugestões ou tirar dúvidas? Entre em contato com a gente \o/ Obrigado por ler!

ASSINE NOSSA NEWSLETTER!
E fique por dentro de tudo o que acontece no Ateliê.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Nosso site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Criando um provedor OAuth was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Trabalhar no Ateliê de Software é muito empolgante! Pois a cada dia que passa, estamos diante de novos desafios. E para essa semana, surgiu a seguinte necessidade: exibir uma coleção de radio buttons do Simple Form, como button group do Bootstrap 4.

Após uma pesquisa pela internet, descobri que o Simple Form não suporta alguns componentes do Bootstrap (dentre deles, o button group).

Neste post irei mostrar qual solução foi adotada para realizar essa integração, solucionar a nossa necessidade e possivelmente a de outras pessoas.

Simple Form

Para exibir um radio button com o Simple Form, podemos utilizar a seguinte instrução:

Se quisermos utilizar um button group, devemos criar um wrapper customizado. Na seção abaixo irei demonstrar como fazer isso.

Adicione o seguinte trecho de código ao arquivo config/initializers/simple_form_bootstrap.rb:

O método wrapper gera uma instância do SimpleForm::Wrappers::Builder. Com isso, podemos utilizar a seguinte instrução:

E o resultado gerado será este:

CSS

Para conseguirmos atingir o nosso objetivo, foi necessário criar um arquivo CSS para customizar o nosso button group. Segue o código abaixo:

Com isso, obtemos o seguinte resultado:

JavaScript

Ao abrir o formulário em modo de edição, o button group não estava exibindo o valor que havia sido selecionado. Isso ocorre devido ao fato do button group utilizar a class active, enquanto o radio button trabalha com o parâmetro checked.

Para corrigir isso, podemos criar um JavaScript que verifica qual radio button está selecionado (checked), e com isso, adicionar a classe active ao botão correspondente.

O seguinte trecho de código foi utilizado nesta etapa:

Conclusão

Por hoje é isso, pessoal! Espero que tenham gostado. Qualquer dúvida, sugestão ou feedback em geral, deixem um comentário, pois estamos sempre monitorando. Mahalo!

Quer fazer sugestões ou tirar dúvidas? Entre em contato com a gente \o/ Obrigada por ler!

ASSINE NOSSA NEWSLETTER!
E fique por dentro de tudo o que acontece no Ateliê.

Dê um alô pra gente! E nos acompanhe nas redes sociais:
→ Nosso site
→ Facebook
→ Instagram
→ Twitter
→ Youtube

Exibindo Radio Buttons como Button Group was originally published in Share! por Ateliê de Software on Medium, where people are continuing the conversation by highlighting and responding to this story.