Design how to structure client-side code

[axelpale]

Aspects:

• components
• routing
• models

[axelpale]

Consider an example application with the following components:

• /: front page
• /account: profile and account settings
• /account/login: login form
• /account/signup: create user account
• /account/reset: reset lost password
• /account/password: change password
• /users: list and manage users
• /users/johndoe: user profile
• /items/2345: an item
• /create: tools to add new items

The components are laid out on a single space, and fully loaded when viewed at close distance. The /create component somehow follows the user or is fixed to the edge of the viewport like a traditional menu.

[axelpale]

Structural requirements:

• Components require a parent space item and the SpaceView to be able to render UI and define interaction.
• Nested components ask for nested routing
• Component should react to changes in data
• Item is modified, data of the item changes, the change is reflected to model.
  • item model is connected to a collection, collection is connected to a server

[axelpale]

Just thoughts... Consider directory structure:

• client/
  • Account/
    • assets/
    • Login/
    • Logout/
    • index.js
    • handlers.js (define how
    • router.js (define URLs that affect Account)
  • assets/
  • Menu/
    • index.js
    • template.ejs
  • index.js

Where capitalized are component classes with methods:

• mount(HTMLElement)
• unmount()

Case:

1. user at home view
2. user presses link "Log in"
3. browser location changes to /account/login
4. a route activates (Account/Login/router.js) and calls login.mount() (in Account/Login/handlers.js)

[axelpale]

Dynamic look-ahead navigation makes things a bit tricky. The navigation structure, forms and so on are handled like content, loaded piece by piece in recursive, depth-limited manner... This seems to generalize to a graph browser where nodes are web applications. But what if two nodes are related, like, a button in one causes a change in another?

[axelpale]

Consider Redux applications. In Redux, there is a single store that is changed via state-changing function called reducer. State changes are then listened. How should this kind of app be structured? Having the three state-models seems overkill: DOM, Space, Redux store. Would it be more flexible and beneficial that Tapspace does not form a state model but instead acts like a functional glue between DOM and the app state (e.g. Redux store). For example jQuery works like such a glue. We should drive Tapspace closer to libs like jQuery.