[client] js: Fetch public conf once from /config; embed.js: Preserve default config values

[ix5]

isso: js: embed.js: Preserve default config values

This way, Isso is not confusing users when a server config value overwrites a client default one, i.e. if the user has not actually attempted to overwrite it.

isso: js, py: Fetch public conf once from /config

This is an improvement on top of: 02f3ea0 "Have client read out shared settings from server (#311)"

So far, the config dict was being sent with the server response when fetching comments from the fetch() / (GET) endpoint.

Remove the config object from fetch() responses and instead let client user the newly created /config endpoint. (see #880)

Extend the JS client api file to fetch from the /config endpoint, which will only happen once via the fetchComments hook on page load.

EDIT: Have a couple of nasty race conditions right now, needs further work. Caused by multiple instances of config copying from default_config, where the templates might receive either a pre-copy or post-copy instance.

[ix5]

cc @pellenilsson @brad, looking forward to your reviews. Hope you can rebase your changes on top of this.

[ix5]

@Kerumen continuing discussion from #842

It seems that in development, window.Isso.fetchComments() reload the whole page. I have to dig more.

That seems strange to me. With the branch from #821, I don't see a refresh of the whole window. Both init() and fetchComments() now do exactly what they're supposed to.

---

But I have discovered another issue which is a race condition during the reading of the default config and fetching of the server config. See this branch with some logging. You need to refresh the page a couple of times to hit it.

comment:
Object { css: true, "css-url": null, "max-comments-top": "inf", "max-comments-nested": 5, "reveal-on-click": 5, avatar: true, "avatar-bg": "#f0f0f0", "avatar-fg": (8) […], vote: true, "vote-levels": null, … }
comment: gravatar
true
comment:
Object { css: true, "css-url": null, "max-comments-top": "inf", "max-comments-nested": 5, "reveal-on-click": 5, avatar: true, "avatar-bg": "#f0f0f0", "avatar-fg": (8) […], vote: true, "vote-levels": null, … }
    avatar: true
    "avatar-bg": "#f0f0f0"
    "avatar-fg": Array(8) [ "#9abf88", "#5698c4", "#e279a3", … ]
    css: true
    "css-url": null
    feed: false
    gravatar: false
    langs: Array(4) [ "en-US", "en", "en", … ]
    "max-comments-nested": 5
    "max-comments-top": "inf"
    "reply-notifications": false
    "reply-to-self": false
    "require-author": false
    "require-email": false
    "reveal-on-click": 5
    vote: true
    "vote-levels": null
    <prototype>: Object { … }

!!!
comment: gravatar
true
# should not be true!
!!!

Setting reply-to-self to false
Setting require-email to false
Setting require-author to false
Setting reply-notifications to false
Isso: Client value 'true' for setting 'gravatar' overridden by server value 'false'.
Since Isso version 0.12.6, 'data-isso-gravatar' is only configured via the server to keep client and server in sync
Setting gravatar to false

GET http://localhost:8080/demo/undefined
[HTTP/1.1 404 NOT FOUND 4ms]

Note conf.gravatar is supposed to be overriden to false because of the server config:

{
  "config": {
    "reply-to-self": false,
    "require-email": false,
    "require-author": false,
    "reply-notifications": false,
    "gravatar": false
  }
}

But in some cases (like the above), it'll result in some instances being set to true and later/earlier(?) evaluating to false.

This is due to some bad importing practices - a lot of code relies on config, templates or i18n but these get imported multiple times from multiple sources, and they're each carrying state instead of being purely functional. I'm not sure what the best way forward is here - have everything originate from embed.js and pass config as a parameter to each successive import/call?

My idea for how the flow should look like is this:

• embed.js loaded
• have default config
• look for data-isso-* vars
• look for endpoint, or fall back to script source
• fetch config
• use fetched config vars to overwrite default
• initialize isso
• render postbox
• fetch comments
• render comments

Further problems

• Class vs instance vars
• Multiple copies of e.g. config, i18n
• Race conditions
• Circular imports

[ix5]

I am positive that by introducing a sort-of lock using wait_for, the races for config options should be fixed. Merging, can still be improved upon later.