Pular para conteúdo principal
Nenhum item encontrado.
Logo do DropboxSign
Por que usar o Dropbox Sign?
Expandir ou recolher o acordeão

O que você é possível fazer

Assinar documentos on‑line
Crie assinaturas eletrônicas
Escolha ou crie modelos
Preencher e assinar PDFs
Concluir contratos on-line
Gerenciamento de documentos
Explorar recursos
Ícone de flecha para direita

Casos de uso

Vendas e desenvolvimento de negócios
Recursos humanos
Startups
Tecnologia financeira
Imobiliária
Serviços sob demanda
Produtos
Expandir ou recolher o acordeão
ícone do Dropbox
Sign
Facilite o envio e a assinatura
ícone do Dropbox
Sign API
Integre a eSign em seus fluxos de trabalho
Ícone de Dropbox Fax
Fax
Envie faxes sem usar um aparelho de fax
Ícone de Integrações do Dropbox
Integrações
Nós vamos até você
Recursos
Expandir ou recolher o acordeão
Blog
Experiência em fluxo de trabalho e novidades sobre produtos
Histórias de clientes
Histórias do mundo real com resultados reais
Central de ajuda
Orientação detalhada para nossos produtos
Biblioteca de recursos
Relatórios, vídeos e folhetos de informações
Desenvolvedores
Preços
Expandir ou recolher o acordeão
Preços do Dropbox Sign
Encontre o plano mais adequado para você
Preços da Dropbox Sign API
Histórias do mundo real com resultados reais
Fale com vendas
Registrar‑se
Fale com vendas
Acessar conta
Expandir ou recolher o acordeão
Dropbox Sign
Dropbox Forms
Dropbox Fax
Conta de avaliação gratuita
Blog
/
Desenvolvedores

React Rocks: Redesign Your Front-End for Composability

by 
Aron Solberg
November 17, 2014
7
minutos de leitura
Redesign Your Front-End for Composability
ícone de dica de ferramenta

Novo visual, mesmo produto incrível! O HelloSign agora é Dropbox Sign.

ícone fechar

Back in May 2014, the Dropbox Sign website (like a lot of others) had a classic view layer consisting of templates, partials, vanilla CSS stylesheets, and a handful of supporting libraries like jQuery. This setup was simple to implement, universally understood, and at the time the original Dropbox Fax site was established in 2010 pretty much the standard way of doing things around the web. 

‍

However, as our platform grew in feature-set and complexity the frontend code began to accumulate signs of “technical debt.” A page that once contained only a handful of simple flows gradually evolved into an intimidating maze of jQuery event handlers and complex JavaScript logic. Each new commit felt like trouble was lurking in hidden places, and even changes that should have been simple became a chore. Not surprisingly the QA time required to deploy new front-end features likewise increased. 

‍

Meanwhile, JavaScript technologies were advancing rapidly and a number of new approaches were gaining momentum, all of which promised a better way of doing things. We decided a little research was warranted to better understand our options. 

‍

Our initial discovery effort involved us looking at a few popular technologies such as Backbone, Knockout, and Angular but for various reasons none of them seemed like a good fit. But then we noticed a relative newcomer on the front-end scene: a small library from Facebook called React. 

‍

At first glance React looked like a lightweight frontend library that focused specifically on the view layer and was generally unopinionated on surrounding technologies. It also appeared to be an excellent choice for writing drop-in replacements (i.e. refactoring code in pieces) for those pages that we weren’t ready to entirely re-write.

‍

Enter React

‍

React brought a number of innovative ideas to the table and it was remarkably easy to pick up. While some frameworks like Angular and Meteor emphasized “two-way data binding” React encouraged the developer to write code in which data flows in only one direction (from parent to child). 

‍

While this might seem like it could be inconvenient, it does have the remarkable advantage of being easy to debug and reason about. Finding where data changes occur usually is a simple matter of finding usages for “setState” which (in a vanilla React implementation) will always be set explicitly. Note: it’s also possible to implement implicit two-way data bindings in React using helpers).

‍

Another innovative feature is the JSX syntax which is how React blends markup and javascript together into a high-level abstraction. It’s a departure from classic unobtrusive JavaScript; but the creators argued that separation-of-technologies is actually not the same thing as separation-of-concerns. The syntax seemed a little strange at first but it was hard to argue with the practicality of the end-result: portable interactive components which contained within them everything needed to declaratively render on a page. 

‍

Speaking of rendering, React does it with a nifty trick. It maintains an in-memory virtual DOM and when updates to the real DOM are required, it calculates a diff and a kind of “shortest path” so that expensive update operations can be minimized. 

‍

The technology was impressive; but we felt even more strongly drawn to the development philosophy. The idea of breaking components up into their constituent parts and nesting them within each other opened up a whole world of possible design patterns. The virtual DOM and JSX syntax were cool, but this composability idea was what really got our interest piqued. After all, the  core design philosophy seemed aimed at solving many of the same problems we were facing in maintaining unwieldy separate technologies and javascript files - we were impressed. 

‍

We decided to design a first simple composable component to see how it would look in our dev stack.

‍

Composable Buttons

‍

Much has already been written about how to use React, so we won’t recreate a tutorial here. But just for context it’s important to know that data exists in one of two forms: props and state. 

‍

Props are passed from parent to child and don’t change directly as a result of user interaction. State on the other hand does change with user interaction and a common pattern is to allow the state of the parent component determine the props which ultimately get passed down to its children. It’s a declarative approach with both data types combined governing how the component will render at any given moment. 

‍

With the basic thought process in mind, let’s dive into a real example to see how we used React to create composable buttons to use in our new design. The first step was to create a base type to provide all the functionality that every button would share. This might remind you a bit of object-oriented programming and indeed the basic tenets are similar: encapsulation and inheritance. 

‍

‍

If we wanted we could extend this in other ways to include things like dimensions and corner style, but this is a great starting point. Now, whenever we need to place a button, we could use this BaseButton and specify all of its styling including text, background-color, hover-color, and font-color. 

‍

A better approach would be to create a higher-level abstraction which has the pre-defined settings for the specific types of buttons that we use in our style guide for example a “GreenButton” and a “BlueButton.” This should help enforce consistency and reduce repetition. 

‍

‍

‍

Now, a quick lookup in our internal style guide should be all that’s required to understand the visual forms possible and the limited props required to make each one work correctly. If a new variation is desired, the groundwork has already been laid to accommodate it. Best of all, we’re confident that using React for this functionality is faster and less-error prone than the way we had done things before.

‍

Composable Modals

‍

Our new design also makes liberal use of popup modals for important user actions. One reason we like the modal approach is it feels less disruptive for things like logging in and signing up a new account. In these moments we want our customers to easily see their origin in the background and be able to return to it by simply closing the modal. 

‍

For the basic styling we’re using Foundation’s Reveal, but for control and behavior we again turned to React. In this case we wanted to build a base modal component which defined all the shared functionality including open/close triggers and required DOM attach points. We also wanted the content to be interchangeable and ideally for them to work in a non-modal context as well. 

‍

Here is an example of a ModalTrigger component which will launch a modal when fired. It accepts the basic props to build the modal itself and also looks for a separate passed in component to render the content (TriggerContent). 

‍

‍

The TriggerContent component will vary but can include things such as the “CreateAccount” form and the “Credit card Payment” form. For reference here’s a slimmed down gist of our “CreateAccount” component which also doubles as a login form and could be used for the TriggerContent prop. 

‍

Now we can render BaseModal component and pass as a prop the CreateAccount component. This will give us the content in modal form.

‍

‍

And the result:

‍

‍

Alternatively, we can use the “isInline” property (which conditionally apply CSS rules) allowing the modal to appear within the normal flow of the page. All other functionality remains the same including form validation, submission, and the overall responsive design.

‍

‍

 Which renders like so:

‍

‍

A different kind of trigger

‍

You may have noticed that we have a “Trigger” prop which is optionally passed into our ModalTrigger. If not present we’ll use anchor text but in many cases it would look a lot nicer to use a button instead. So as a final example, here is how we might utilize the “BlueButton” component we built previously to act as the trigger. This really illustrates how React's composability makes it so powerful, versatile, and fun to work with. 

‍

‍

Looking ahead

‍

Overall our first experience using React was a positive one. We’re planning to use the knowledge we gained from this effort and apply it toward future redesign and development efforts (including our internal pages, stay tuned!). We’re also looking forward to continue working with React to support cleaning up old code while simultaneously adding new features to support our expanding user base. 

‍

Also on the horizon for us will likely be the inclusion of a model layer to better manage data flow from the backend to the frontend. Some have chosen to implement Backbone alongside React for just this purpose while others have gone a different route and used an accompanying Facebook library called Flux. 

‍

Regardless of which approach we take, the lines of abstraction in our front-end stack have been drawn and future improvements seem easily within reach.We hope you enjoyed this brief foray into how we used React to level-up our frontend code. 

‍

If you liked this article make sure to check out the next two parts where we'll talk about styling and our internal developer workflow. 

‍

If you’re a developer and this stuff speaks to you on a deeper level give us a shout, we’re hiring.If you want to hop into our API documentation, visit here.

Fique por dentro

Pronto! Verifique sua caixa de entrada.

Thank you!
Thank you for subscribing!

Lorem ipsum

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Lorem ipsum
Ícone de flecha para direita
ícone fechar

Up next:

Ilustração em close-up de uma assinatura manuscrita, representando soluções modernas de assinatura digital.
Desenvolvedores
15
minutos de leitura

Como integrar o Dropbox Sign ao Ruby on Rails: um tutorial passo a passo

Ilustração em close-up de uma assinatura manuscrita, representando soluções modernas de assinatura digital.
Desenvolvedores
15
minutos de leitura

Dropbox Sign vs. SignNow for developers

Modelo

Employment contract template

Produtos
Dropbox SignDropbox Sign APIDropbox FaxIntegrações
Por que o Dropbox Sign?
Assinaturas eletrônicasAssinar documentosAssinar e preencher PDFsContratos on-lineCrie assinaturas eletrônicasEditor de assinaturasAssine documentos do Word
Atendimento
Central de ajudaFale com vendasEntrar em contato com o atendimentoGerenciar cookiesIntrodução: Dropbox SignIntrodução: Dropbox Sign API
Recursos
BlogHistórias de clientesCentral de recursosGuia de legalidadeCentral de confiança
Parceiros
Parceiros estratégicosLocalizador de parceiros
Empresa
CarreirasTermosPrivacidade
ícone do Facebookícone do Youtube

Métodos de pagamento aceitos

Logo da MastercardLogo do VisaLogo da American ExpressLogo do Discover
Emblema de conformidade CPAEmblema de Conformidade com HIPAAEmblema da Sky High Enterprise ReadyEmblema do Certificado ISO 9001

As assinaturas eletrônicas do Dropbox Sign são juridicamente vinculativas nos Estados Unidos, União Europeia, Reino Unido e muitos outros países do mundo.
Para mais informações, consulte nossosTermos e Condições e nossa Política de Privacidade