# Documentation for "Soppy Apps"

sop•py app
/ˈsäpē ap/

An app that keeps your views well-hydrated with all the data it needs—without all the hassle of managing server-side APIs and client-side state.

# The Backstory

To understand where the "Soppy App" concept came from, read this post on Medium → A Ready-to-Try Concept in Response to "Second-guessing the modern web".

# Routing Fun

The Soppy App concept really hinges on the app's routing. When the backend and frontend work together on the routing, the data can flow back and forth easily.

This is pretty straight forward most of the time, but it may get fuzzy around some edge-cases. Here is where we explore and aim to normalize these edge-cases with some of our opinions.

# Case #1 - Normal Page Navigation

On page load the server returns the view with data.

On page navigation the current URL path becomes a GET request, and the server returns the data in JSON format.

On <soppy-link> hover you have the option to "preload" the data by running the GET request on hover and then injecting the preloaded data on click.

# Case #2 - Form Submissions

On submit it will use the <form>'s action (defaulting to current URL path) and method (defaulting to POST).

Using <soppy-link> to submit a form is also possible. Just add the method attribute, and vue-soppy will take care of the rest.

# Case #3 - Redirects

If the data returned contains a to property, vue-soppy will redirect to that URL path on success.

# Case #4 - Authentication

If the request returns 401 status, the SoppyBus (a vue event "bus") will emit the unauthorized event. Your router can listen for this event and redirect to the appropriate page.

On successful login be sure to return a to property so vue-soppy can redirect accordingly.

# Case #5 - Modal Windows


This is still under discussion

First, we need to ask: Do we want our modals to have their own routes or not?

If modals have routes

  • Routes could have a /modal/my-modal-name convention
  • Form submission from a modal may be easier to manage
  • It's easier to link directly to a modal from any part of the site
  • If you want a lot of your data editing forms in a modal, then this may be the best way to do it.
  • How could you make sure the whole page isn't re-rendered (if we want the content under the modal to appear the same)?

If modals don't have routes

  • You don't have to worry about what's rendering below them.
  • You don't have to worry about going back to the correct URL when the modal is closed.
  • If you have pages dedicated to editing your data, and you're using modals for things like a photo gallery, then this may be the way to go.

Another possibility is using pseudo routes with the hash (ie. #/modal/my-modal-name) in the URL.

  • This means that all the modals are handle exclusively on the frontend. The FE router would be notified of a change, but it wouldn't send off a GET request.
  • You get all the benefits of modals don't have routes above.
  • But it wouldn't work well if the modal needed data from the server that wasn't already loaded on the page.
  • If the page DID have the data, then you wouldn't be able to (easily) show that modal on some other page. In that case, you may as well go the modals have routes route.

# Case #6 - Filtering, Sorting, and Pagination


This is still under discussion

I'm thinking of just using query params, but I don't want the controller getting too messy. You begin losing the tight 1-to-1 routing for frontend and backend.

For pagination something like /page/2 in the route would be fine, until you wanted to add the option to how many you want to show per page.

# Case #7 - Literally One-Page-App


This is still under discussion

If all the interaction for your app happens on one URL path, then a Soppy App, may not work for you. Maybe just the plain API/state-management is better in this case...

# Case #8 - Real-Time Updates


This is still under discussion

Let's say you're not using websockets, but you want the data on your page refreshed frequently...