{"id":1737,"date":"2014-02-19T00:00:00","date_gmt":"2014-02-18T23:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2014\/02\/19\/1694\/"},"modified":"2014-02-19T00:00:00","modified_gmt":"2014-02-18T23:00:00","slug":"1694","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2014\/02\/19\/1694\/","title":{"rendered":"A simple JavaScript component architecture (first draft)"},"content":{"rendered":"

Reusable user interface components for Web development are trending<\/a>. I\u2019ve been thinking about them for quite some time now (see JavaScript components<\/a> from almost a year ago). Now that we\u2019re building a new UI<\/a>, we need to finally decide on something and start using it!<\/p>\n

While we\u2019ve done single page Web apps<\/a> in the past, the UI we\u2019re building now will start out as a more traditional Web site with distinct pages<\/strong>, plus some dynamic elements within the page. We want to keep things as simple as possible for version one, so we\u2019ll render most of the HTML on the server (no need to generate HTML in JavaScript). Elements that are refreshed via Ajax will have to redraw themselves, but their HTML can be sent from the server for now. Still, the component architecture we\u2019re choosing now must work for single page apps as well, so that we can switch if needed.<\/p>\n

We\u2019re doing a lot of customization in our projects. We want a set of configurable UI widgets<\/strong> that can be freely combined when building custom pages, and partners need to be able to add their own widgets. The UI will be based on the Bootstrap framework<\/a>, and we want to be able to integrate widgets from libraries like jQuery UI<\/a>.<\/p>\n

The MVC (model \/ view \/controller) approach<\/strong> seems to make sense; maybe as implemented in the separable model architecture<\/a> from Java Swing components: A component can manage its own data, or be configured to share data with other components. Our UI components should be \u201cloosely coupled\u201d, exclusively communicating through events in order to avoid breakage if a component is missing or not initialized (and to make replacing components easier). The Twitter Flight framework<\/a> has been a wonderful inspiration, make sure to read about it! We\u2019ve extended their event approach a little bit: Events can collect and return responses using event.result<\/a> in jQuery custom events (with promises\/Deferred<\/a> for asynchronous results).<\/p>\n

There\u2019s dozens of JavaScript frameworks out there, but we\u2019re not too eager to rely on one of those. We improve and support our software products for years; it\u2019s bad for us if a framework dies or changes its direction. That\u2019s why we\u2019ll probably go for frameworkless JavaScript<\/a> \u2013 or rather, we\u2019ll build our own small framework<\/strong>. (Relying on jQuery<\/a> as the only hard dependency is hopefully okay.)<\/p>\n

Small is important to us. The simpler, the better \u2013 we need to find a clever, powerful, extensible, future-proof architecture with minimal lines of code. (Good luck with that, I know.)<\/p>\n

This demo page<\/a> (JavaScript code on Github<\/a>) contains the first draft<\/strong> of that mini-framework: Two embedded Google Maps that, when you drag them, send the address in the map center to a text input field. It won\u2019t make sense for you if you aren\u2019t a Web developer interested in JavaScript \ud83d\ude42 But if you are, I\u2019d love to hear your feedback!<\/p>\n","protected":false},"excerpt":{"rendered":"

Reusable user interface components for Web development are trending. I\u2019ve been thinking about them for quite some time now (see JavaScript components from almost a year ago). Now that we\u2019re building a new UI, we need to finally decide on something and start using it! While we\u2019ve done single page Web apps in the past, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1737","post","type-post","status-publish","format-standard","hentry","category-weblog"],"share_on_mastodon":{"url":"","error":""},"_links":{"self":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/comments?post=1737"}],"version-history":[{"count":0,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1737\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}