├── LICENSE ├── README.md ├── cache.js ├── check.js ├── example ├── chat │ ├── db.js │ ├── index.js │ └── static │ │ └── style.css ├── clock │ └── index.js ├── fs │ ├── files │ │ ├── new_file │ │ ├── new_file.txt │ │ ├── new_file2.txt │ │ ├── new_file3.txt │ │ ├── new_file4.txt │ │ ├── new_file5.txt │ │ └── new_file6.txt │ ├── index.js │ └── static │ │ └── style.css └── tabs │ └── index.js ├── index.js ├── names.js ├── package.json └── util.js /LICENSE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2018 Dominic Tarr 2 | 3 | Permission is hereby granted, free of charge, 4 | to any person obtaining a copy of this software and 5 | associated documentation files (the "Software"), to 6 | deal in the Software without restriction, including 7 | without limitation the rights to use, copy, modify, 8 | merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom 10 | the Software is furnished to do so, 11 | subject to the following conditions: 12 | 13 | The above copyright notice and this permission notice 14 | shall be included in all copies or substantial portions of the Software. 15 | 16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 17 | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES 18 | OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 19 | IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR 20 | ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, 21 | TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE 22 | SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # coherence 2 | 3 | frontend framework based on a cache `coherence` 4 | protocol. 5 | 6 | ## Architecture 7 | 8 | Take a traditional RESTful http application, but then supercharge it with 9 | _cache invalidation_. This means just write templates and queries, rendered 10 | serverside, but then the front end checks at certain appropiate times wether 11 | parts of the page have changed, and if so updates just those parts. 12 | Because they way the cache (front end views) are invalidated and updated is 13 | standardized into a protocol, _it is not necessary to write any custom front end javascript_. 14 | 15 | To facillitate this, the back end needs to provide a little extra information 16 | and constraints. Firstly, we assume that application is comprised of a number of views, 17 | which are composed from a layout and partials. The "layout" is a wrapper around every 18 | page in the app, usually adding nav and footer etc. "partials" are templates for just 19 | a part of the page, that are reused across multiple views. This is a very common way 20 | to create an http application. The different thing, is that it needs to be possible 21 | to request just a single partial at a time (as well as the full page) via an http request, 22 | (without the layout). And finally, each rendered partial must have the url to update it 23 | in an attribute, and an cache id and state. Similar to an [etag](https://en.wikipedia.org/wiki/HTTP_ETag) 24 | header (but more powerful) but it represents the cache state of a single element. 25 | 26 | Several examples are provided, the simplest is `examples/clock/index.js`. 27 | it renders a single partial (displaying the current time) and it updates every second. 28 | This `data-id` `data-href` and `data-ts` must be provided. The front end calls 29 | the server to check if it has something newer that `data-ts` and if so, rerequests 30 | the partial from `data-href`. 31 | 32 | ``` html 33 |