{"_id":"5734c65157245917005ea2bf","user":"5730eaf719c1e00e006d215f","parentDoc":null,"version":{"_id":"5730eb946b55e93400b32ab1","project":"5730eb946b55e93400b32aae","__v":4,"createdAt":"2016-05-09T19:57:08.646Z","releaseDate":"2016-05-09T19:57:08.646Z","categories":["5730eb946b55e93400b32ab2","5734b41b9c2cf82900b243ee","5734c6986d9a38200073dd32","5734cea86d9a38200073dd5a"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"0.3.25","version":"0.3.25"},"__v":0,"category":{"_id":"5730eb946b55e93400b32ab2","__v":0,"version":"5730eb946b55e93400b32ab1","project":"5730eb946b55e93400b32aae","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-09T19:57:08.664Z","from_sync":false,"order":9999,"slug":"documentation","title":"Documentation"},"project":"5730eb946b55e93400b32aae","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-05-12T18:07:13.377Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"## Architectural Philosophy\n\n> \"We need to stop thinking like hackers, and instead, be surgeons with the code.\" - John Hewin Hatcher\n\nThis library was designed with the ideas that each component should be a self-contained set of code. Each component should be split into multiple layers, with each layer abstracting certain parts of the logic.\n\n - The root class of all classes is the baseComponent. This class handles the most low-level details, and will define a very basic getter / setter. All child classes must override the render() method. This functions like an Abstract Class in Java\n - Each UI component should inherit from the baseComponent class and supplement and/or override four functions: the constructor, get(), set(), and render() with the UI specific details. If a component is sufficiently more complicated, it should extend its \"baseUIComponent\" and layer on the additional behaviors in a child class.\n - As Each Component is self-contained, certain complicated UI components (like Typeahead, for example) can be created as a composite of a couple smaller, simpler components (ListView and TextInput).\n\nEach component must be able to run on both the server-side, and the client side. If the component requires some set of data, one can expose a \"fetch\" function that allows the consumer to define the where-and-how the results happen. In addition, no UI component should throw an error. It should have smart defaults, and it should be able to gracefully handle malformed input.\nUnderlying the components is an internal Pub-Sub model of communication. Each component determines when to \"publish\" state changes. Any other components may \"subscribe\" to these changes, and fire off actionHandlers in response. This mode of inter-component communication was inspired partly by Facebook's Flux Paradigm.","excerpt":"","slug":"architectural-philosophy","type":"basic","title":"Architectural Philosophy"}

Architectural Philosophy


## Architectural Philosophy > "We need to stop thinking like hackers, and instead, be surgeons with the code." - John Hewin Hatcher This library was designed with the ideas that each component should be a self-contained set of code. Each component should be split into multiple layers, with each layer abstracting certain parts of the logic. - The root class of all classes is the baseComponent. This class handles the most low-level details, and will define a very basic getter / setter. All child classes must override the render() method. This functions like an Abstract Class in Java - Each UI component should inherit from the baseComponent class and supplement and/or override four functions: the constructor, get(), set(), and render() with the UI specific details. If a component is sufficiently more complicated, it should extend its "baseUIComponent" and layer on the additional behaviors in a child class. - As Each Component is self-contained, certain complicated UI components (like Typeahead, for example) can be created as a composite of a couple smaller, simpler components (ListView and TextInput). Each component must be able to run on both the server-side, and the client side. If the component requires some set of data, one can expose a "fetch" function that allows the consumer to define the where-and-how the results happen. In addition, no UI component should throw an error. It should have smart defaults, and it should be able to gracefully handle malformed input. Underlying the components is an internal Pub-Sub model of communication. Each component determines when to "publish" state changes. Any other components may "subscribe" to these changes, and fire off actionHandlers in response. This mode of inter-component communication was inspired partly by Facebook's Flux Paradigm.