move to single-page app for configuration

[fardog]

currently we treat each of the configuration pages as discrete, with context being written into the page by the backend; preferably we'd be treating this as a single page app.

should work roughly as follows:

• backend delivers initial page context, which includes all currently configured heads/tentacles/relations to speed page load (doesn't require xhr to retrieve initial data)
• all operations are performed within single page app (CRUD on heads/tentacles)
• page context should be refresh-able via an api endpoint

for these purposes, I'd like to see us centralize any pieces behind a distinct REST-ful set of routes, propose:

• /api/v1
  • GET returns list of endpoints
• /api/v1/heads
  • GET, POST, PUT, PATCH, DELETE as expected
• /api/v1/tentacles
  • GET, POST, PUT, PATCH, DELETE as expected

Each of these would speak JSON; i can define the format when/if we decide to implement.

I suppose i need to better understand the full organization of things to know if tentacles should actually be under /api/v1/heads/head-slug/tentacles, or if both endpoints should exist (all vs tentacles that just belong to a head).

[fardog]

additional comment, this'd mean that we'll doing front-end routing; i'm gonna prefer history.pushstate routing to hash-routing, although we can do ether depending on which browsers we'd like to support (i'd rather support one or the other, not both)

doing history.pushstate routing will mean that we'll have to deliver the same page from the backend filled with the correct context for any of the pages that are used for admin; currently

• /
• /add-tentacle
• /add-head

i'd probably move these to more REST-like urls for the frontend, especially since we need to implement edit/delete (which is currently broken on master branch)

• /
  • list everything
• /heads
  • create new head
• /heads/head-slug
  • edit existing head (with option to delete)
• /tentacles
  • create new tentacle
• /tentacles/tentacle-slug
  • edit existing tentacle

this is part of why an /api/v1/heads/head-slug/tentacle might make sense; since these are re-usable components we could display a list of tentacles for a specific head on its edit/info page.

[Gastove]

Would love to hear thoughts on how to achieve front-end routing; I've never grokked how to separate back-end from front-end routing without making the front end an entirely separate project (which might be the right answer?)

[jarofghosts]

secretary and accountant are nice.

[jarofghosts]

i wish there was a better solution for doing pushstate routing that didn't basically require duplicating routes front <-> back