|
| 1 | +<html> |
| 2 | + <head> |
| 3 | + <title>Contracts</title> |
| 4 | + <link href="lib/bootstrap.css" rel="stylesheet" /> |
| 5 | + </head> |
| 6 | + <body> |
| 7 | + <section class="container"> |
| 8 | + <h1>Contracts</h1> |
| 9 | + <div class="row"> |
| 10 | + <div class="col-sm-12"> |
| 11 | + <p> |
| 12 | + Public facing functions can be considered a contract. |
| 13 | + When you define a function you are establishing a set of desired actions that other functions depend on remaining consistent. |
| 14 | + If you change a function that is called throughout the application it should maintain its contractual obligations (or else you will need to refactor all the calls made to te function). |
| 15 | + By establishing a contract the function can be more easily re-used and is a great tool for isolating complexities. |
| 16 | + </p> |
| 17 | + <p>Obligatory wikipedia link: <a href="https://en.wikipedia.org/wiki/Design_by_contract">Design by Contact</a></p> |
| 18 | + </div> |
| 19 | + </div> |
| 20 | + </section> |
| 21 | + <section class="container"> |
| 22 | + <h1>Components as Contracts</h1> |
| 23 | + <div class="row"> |
| 24 | + <div class="col-sm-12"> |
| 25 | + <p> |
| 26 | + Components work like statefull functions and can be designed in a contractual manner. |
| 27 | + In general components should only concern themselves with rendering the DOM and handling user interactions. |
| 28 | + If the results of those user interactions extend beyond the component itself then the handling should be done outside the component. |
| 29 | + This can be done through callbacks associated to the component (onChange, onClick, etc) or by putting an event on a channel. |
| 30 | + Not only does this keep our components lean but it makes it easier to unit test since our blocks of code are seperated by concerns. |
| 31 | + </p> |
| 32 | + </div> |
| 33 | + </div> |
| 34 | + </section> |
| 35 | + <section class="container"> |
| 36 | + <h1>Components as Stories</h1> |
| 37 | + <div class="row"> |
| 38 | + <div class="col-sm-12"> |
| 39 | + <p> |
| 40 | + Components (and programming in general) allow the user to <a href="https://en.wikipedia.org/wiki/Choose_Your_Own_Adventure">"choose your own adventure"</a>. |
| 41 | + At each event the component updates state and the story progresses. |
| 42 | + Wherever the user chooses to progress the story should be encapsulated in a method. |
| 43 | + Wherever the component chooses something to render based on the current story line should also be encapsulated in a method. |
| 44 | + The alternative to this is to attempt to pack more logic into the "render" method which is harder to test. |
| 45 | + By delegating functionality to component methods the component contract becomes more obvious and other developers can more quickly understand how the component progresses the story. |
| 46 | + </p> |
| 47 | + </div> |
| 48 | + </div> |
| 49 | + </section> |
| 50 | + <div class="footer container"> |
| 51 | + <ul class="pagination"> |
| 52 | + <li><a href="lesson2.html">«</a></li> |
| 53 | + <li><a href="lesson1.html">Lesson 1</a></li> |
| 54 | + <li><a href="lesson2.html">Lesson 2</a></li> |
| 55 | + <li><a href="lesson3.html">Lesson 3</a></li> |
| 56 | + <li class="active"><a href="lesson4.html">Lesson 4</a></li> |
| 57 | + </ul> |
| 58 | + </div> |
| 59 | + </body> |
| 60 | +</html> |
0 commit comments