メイン コンテンツにスキップする
該当する項目はありません。
Dropbox Sign のロゴ
Dropbox Sign が選ばれる理由
アコーディオンの展開と折りたたみ

機能

ドキュメントへのオンライン署名
電子署名の作成
テンプレートを選択または作成する
PDF への入力と署名
契約書へのオンライン署名
ドキュメント管理
機能を見る
右矢印のアイコン

ユースケース

セールス/ビジネス開発
人事
スタートアップ
金融テクノロジー
不動産
オンデマンド サービス
製品
アコーディオンの展開と折りたたみ
Dropbox のアイコン
Sign
手軽に送信、手軽に署名
Dropbox のアイコン
Sign API
電子署名をワークフローに統合
Dropbox Fax のアイコン
Fax
ファクス機なしでファクスを送信
Dropbox インテグレーションのアイコン
インテグレーション
さまざまなツールと連携
リソース
アコーディオンの展開と折りたたみ
公式ブログ
ワークフローの専門知識と製品ニュース
お客様の体験談
実際の導入事例とその成果
ヘルプセンター
当社製品の詳細ガイド
リソース ライブラリ
レポート、動画、情報シート
開発者向け情報
価格
アコーディオンの展開と折りたたみ
Dropbox Sign の価格
ニーズに合わせてお選びください
Dropbox Sign API の価格
実際の導入事例とその成果
セールス担当に連絡
登録
セールス担当へ連絡する
ログイン
アコーディオンの展開と折りたたみ
Dropbox Sign
Dropbox Forms
Dropbox Fax
無料トライアル
公式ブログ
/
開発者向け情報

React Rocks: Redesign Your Front-End for Composability

by 
Aron Solberg
November 17, 2014
7
分(記事閲覧時間)
Redesign Your Front-End for Composability
ツールチップのアイコン

新しい名前でも変わらぬ高品質!HelloSign の名称が Dropbox Sign になりました。

閉じるアイコン

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.

効率を維持

完了しました。受信トレイをご確認ください。

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
右矢印のアイコン
閉じるアイコン

Up next:

手書き署名のクローズアップ イラスト。最新のデジタル署名ソリューションを表しています。
開発者向け情報
15
分(記事閲覧時間)

Dropbox Sign と Ruby on Rails の連携:チュートリアルで詳しい手順をご紹介

手書き署名のクローズアップ イラスト。最新のデジタル署名ソリューションを表しています。
開発者向け情報
15
分(記事閲覧時間)

Dropbox Sign vs. SignNow for developers

イベント

高速で安全な電子署名ワークフロー:Twilio API による SMS 署名者認証の実装

製品
Dropbox SignDropbox Sign APIDropbox Faxインテグレーション
Dropbox Sign が選ばれる理由
電子署名ドキュメントへの署名PDF への入力と署名オンライン契約書電子署名の作成署名エディタWord ドキュメントへの署名
サポート
ヘルプセンターセールス担当に連絡サポートへのお問い合わせCookie の管理スタート ガイド:Dropbox Signスタート ガイド:Dropbox Sign API
リソース
公式ブログお客様の体験談リソース センター適法性ガイドトラスト センター
パートナー
戦略的パートナーパートナー ロケーター
会社
採用情報利用規約プライバシー
Facebook のアイコンYouTube のアイコン

利用可能なお支払い方法

Mastercard のロゴVISA のロゴAmerican Express のロゴDiscover のロゴ
CPA 準拠のバッジHIPAA 準拠のバッジSky High Enterprise Ready のバッジISO 9001 認証のバッジ

Dropbox Sign の電子署名は、米国、欧州連合、英国などを含め、世界中の多くの国で法的に有効です。
詳細については、利用規約およびプライバシー ポリシーをご覧ください。