Giter VIP home page Giter VIP logo

Comments (4)

cbredesen avatar cbredesen commented on June 10, 2024

I would restate this as: "include-agnostic chrome injection". Tying the SSI's to explicit chrome paths requires updates to apps when aspects of the common chrome change (if it happens) or when you want to switch to different themes.

Additionally, injecting chrome onto a pure HTML page feels pretty magical and I don't think it'd be hard to get right. Of course you can always support explicit tokens as well.

from spaship.

Jared-Sprague avatar Jared-Sprague commented on June 10, 2024

Ok yeah I renamed the title. This is what @mwcz was thinking of doing with the SPA_HEAD annotation. But the magical regex based method where you don't have to put anything in your HTML also a possible future enhancement.

from spaship.

mwcz avatar mwcz commented on June 10, 2024

Just making a note here that if we decide to go this route, spandx should be updated to support the same chrome injection approach.

Here's the system I was thinking of for injecting chrome. Actually, not just chrome but SSI snippets in general.

Here's a simplified "autosync" configuration that will fetch chrome's head, header, and footer every 5m. @Jared-Sprague++

  "autosync": {
    "enabled": true,
    "targets": [
      {
        "name": "chrome-head",
        "interval": "5m",
        "source": {
          "url": "https://access.redhat.com/services/chrome/head"
        }
      },
      {
        "name": "chrome-header",
        "interval": "5m",
        "source": {
          "url": "https://access.redhat.com/services/chrome/header"
        }
      },
      {
        "name": "chrome-footer",
        "interval": "5m",
        "source": {
          "url": "https://access.redhat.com/services/chrome/footer"
        }
      }
    ]
  }

With that config in place, the chrome snippets will be available on disk and ready to be SSI'd. Requiring developers to know the filepaths to the snippets would be unfortunate, so I'd like to allow them to reference the snippets by the name property. We would provide an SSI-like comment syntax to include SPAship autosync snippets.

<!DOCTYPE html>
<html>
  <head>
    <!-- ship chrome-head -->
  </head>
  <body>
    <!-- ship chrome-header -->
    <h1>Hi</h1>
    <!-- ship chrome-footer -->
  </body>
</html>

During SPA deployment, SPAship would replace those comments with true Apache SSI comments.

<!DOCTYPE html>
<html>
  <head>
    <!--#include virtual="/init.html" -->
    <!--#include virtual="/chrome/head/$locale/head.html" -->
  </head>
  <body>
    <!--#include virtual="/chrome/header/$locale/header.html" -->
    <h1>Hi</h1>
    <!--#include virtual="/chrome/footer/$locale/footer.html" -->
  </body>
</html>

Including snippets by name would be great for developer convenience.

But to @cbredesen's point, we can probably come up with a generalized approach for automatically SSI'ing autosync snippets as well.

The questions that occur to me are:

  1. should the injection be regex-based implementation, such as replace </body> with snippet(chrome-footer) + </body> or HTML parser based? Gut: probably regex
  2. how should this be configured? The configuration would tell SPAship to replace <body> with chrome-header, </body> with chrome-footer, etc. Something like this:
    {
      "replace": {
        "<head>": {
          "snippet": "chrome-head",
          "preserve": "before" // keep the original match ("<head>") and put it before the snippet
        },
        "<body>": {
          "snippet": "chrome-header",
          "preserve": "before" // keep the original match ("<body>") and put it before the snippet
        },
        "</body>": {
          "snippet": "chrome-footer",
          "preserve": "after" // keep the original match ("</body>") and put it after the snippet
        }
      }
    }
  3. where should the configuration live? It could be in the autosync targets config (ie, global, injection is applied to all SPAs deployed with SPAship), or the config could be in each SPA's config file. Gut: global
  4. if the configuration is applied to all SPAs, should SPAs be able to opt out? Gut: yes

from spaship.

mwcz avatar mwcz commented on June 10, 2024

I think this should be a priority post-MVP. It definitely isn't as important as Akamai cache busting, but I think it's pretty important to provide shorthands for ESI snippets.

from spaship.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.