search

devpunks / snuggsi

snuggsi ツ - Easy Custom Elements in ~1kB
https://snuggsi.com
MIT License
395 stars 17 forks source link

HTTP Resource Representation Variants #164

Closed snuggs closed 6 years ago

snuggs commented 6 years ago

This was already implemented but was sporadically problematic with indeterministic bugs. In other words...duct taped together with no tests. Tests now thanks to tap(e).

Installation

Ability to "install" snuggsi packaged library from https://snuggsi.es with the following:

<script src=//snuggsi.es></script>

Or from mounting server middleware

server.js

app // Express or Koa
  .use ( snuggsi )

index.html

<!-- served from `/snuggsi` endpoint (minified and compressed) -->
<!-- (Javascript / Ecmascript negotiated on browser capabilities) -->
<!-- (gzip / brotli negotiated on browser capabilities) -->
<script src=/snuggsi></script>

<!-- served from `/snuggsi` endpoint (minified and compressed) -->
<!-- (Javascript / Ecmascript negotiated on browser capabilities) -->
<script src=/snuggsi?debug></script>

<!-- Ecmascript version (minified and compressed) -->
<!-- (gzip / brotli negotiated on browser capabilities) -->
<script src=/snuggsi.es></script>

<!-- Ecmascript version (uncompressed) -->
<script src=/snuggsi.es?debug></script>

<!-- JavaScript version (minified and compressed) -->
<!-- (gzip / brotli negotiated on browser capabilities) -->
<script src=/snuggsi.js></script>

<!-- JavaScript version (uncompressed) -->
<script src=/snuggsi.js?debug></script>

References:

Resource Representations

Resource Default HTML GET / Accept: text/html

Resource Default CSS GET / Accept: text/css

Resource Default Javascript GET / Accept: */*

Will determine whether or not to serve modern Ecmascript or legacy JavaScript

GET /snuggsi

Will determine whether or not to serve modern Ecmascript or legacy JavaScript

GET /snuggsi.es

GET /snuggsi.js

References

ES6 Modules & Client/Server support

Anyone touching an app in the browser should at least get familiar. /cc @mrbernnz @btakita @halorium @janz93 @pachonk @robcole @scottmacdowell @kurtcagle @johnrlive

tmornini commented 6 years ago

@snuggs WOW! Huge piece of work!

snuggs commented 6 years ago

@tmornini indeed! And VERY well tested :-)

mrbernnz commented 6 years ago

@snuggs did this PR really need 250+ commits?

tmornini commented 6 years ago

@mrbernnz Strange question to ask when staring at a 250+ commit PR. πŸ˜„

Of course, @snuggs may well decide to do some rebasing before going to master.

brandondees commented 6 years ago

what is this, github golf? ⛳️

tmornini commented 6 years ago

@brandondees If so, we're going to have to start calling @snuggs "Tiger" πŸ˜„

snuggs commented 6 years ago

There's also an added 150-200 tests as well @mrbernnz πŸ˜„. there are over 100+ different permutations for matching routes to endpoints with HTTP verbs. Let alone content negotiation for the types. Imagine that truth table. Truth be told (pun intended) surprised it's not 1,000 commits knowing me. I just want this thing DONE. I'm Also working with MDN, WHATWG, and W3C on doing SOUND HTTP Documentation for the web. Let's just say it doesn't move as fast and this PR is a cumulation of much to do with https://github.com/devpunks/snuggsi/issues/71. As of this year we are in a better place to implement HTTP Resource Variants (ne. Content Negotiation) which is EXTREMELY IMPORTANT related to preloading. (Preload. HUH?! What is it good for?)

Just be readin' up on the description links about HTTP variants and resources....That is unless you want to slang commits too! ;-)

You will see that (finally) we are moving in a direction towards HTTP that @tmornini and I been talking about for damn near a decade. HTTP > MVC. @brandondees @janz93 @pachonk I came across and added some contribution to a nice little Ruby library Flame is based on many of the same principles of this PR.

The intent of this PR is because i'm sick of having a "God directory" for static assets and endpoints when that's not how HTTP works. Also the "front end" paradigm is now a grey area as Links, Resources, preloading, prefetching IS REAL AND READY TODAY. Specs are just relying on people to implement...(since 1999) /cc @btakita @codeSnorter @kurtcagle

foo/index.es

class { // this is a resource. You "route" to it.
  // You get GET, HEAD, OPTIONS(I think?) for free because the HTTP spec says so

  options (context) // this should be handled by CORS. Resource knows supported methods ;-)
    { context.status = 204; context.body = 'Or you could monkeypatch but not advisable' }

  // Usually non-safe methods go here
  put (context) {}

  post (context) {}

  delete (context) {}

  // all other 50+ HTTP verb methods not defined issue a 405 Not Allowed on the resource.
  // **** It never was 404 but framework authors got lazy. ****
  // any GLOBAL HTTP method returns a 501 Not Implemented
  // and can be configured from server. (As the spec states)
  // @tmornini GET / PURGE is where caching is done YES?! ;-) 
  // The spec allows custom verbs/codes like PURGE & 420. Can easily be defined here.
  // e.g. GET /foo/bar.html doesn't need implementation. Just send bar.html from /foo dir.
  // https://stackoverflow.com/questions/35632607/is-the-http-method-purge-idempotent-in-varnish
}

server code somewhere

mount `foo` // or
route `/some/other/endpoint/{id}` (Resource `foo`)
// etc. or some other api. But that's all I wanna do. Rise repeat for next route
// so far haven't seen more terse/lazy code to perform what we want to do.
// An ENDPOINT is nothing more than route + method on resource.

Amazes me we took this long to realize there are no Controllers....only Resources...The http spec says so.

To be clear this is for internal use only and allows me to be dry with the many projects that all require this boilerplate BS. (including yours @mrbernnz). I refuse to use YAAF (Yet Another (wrong) Abstraction Framework).

P.S. There's a test for every single one of those permutations as well 😎:

We got route tokenization (e.g./foo/{id}/bar/{baz}) of routes for free from the code that does tokenization of custom elements. @tmornini @mrbernnz I never knew how cool / painful string manipulation was lol.

snuggs commented 6 years ago

@tmornini @mrbernnz @brandondees interesting... Feeling even better about this PR.

How many frameworks you think would go πŸ’₯ πŸ’£ if you went back in retrospect and implemented the HTTP spec correctly....

https://github.com/gin-gonic/gin/issues/20 https://github.com/julienschmidt/httprouter/pull/51 https://github.com/julienschmidt/httprouter/issues/30 https://github.com/julienschmidt/httprouter/issues/52

brandondees commented 6 years ago

@snuggs hard to say i could expect any of them to work with it fully without taking it all back to the drawing board. Looks like the example cited is the closest thing I know of, and still doesn't have all the kinks worked out yet.

Imagine if you could run a standard suite of tests that could assert spec compliance for a given implementation...

snuggs commented 6 years ago

Imagine if you could run a standard suite of tests that could assert spec compliance for a given implementation... @brandondees

Interesting you say this. About a year ago @tmornini and I had a discussion about versions/testing "User land" tools based off the living specs (As opposed to canonical apps that end-use-developers create that don't have failing tests appear out of nowhere). I mentioned to him how even I don't know if the suite passes and that's great we have CI. The specs change frequently and implementation can break just from an update to WPT (Web Platform Tests. The test suite that ALL browsers MUST adhere to.) And we use JSDOM which basically creates an in memory "browser" that is merely a stubbed implementation of said WPT/WHATWG/W3C specs.

Browser vendors are constantly breaking tests (that were previously passing). An update to specs (therefore update to WPT) triggers failing tests and tell the browsers what they MUST implement immediately. They then implement bugs with respective vendors. None of the spec's concern either....an implementation detail. Personal problem of the browser vendors if you will. We are also under the same scrutiny which I think is a great thing.

That being said, to make a long story longer your thoughts may not be too out of reach in 2018. We're definitely on that path already (intentionally). #YouHeardItHereFirst

snuggs commented 6 years ago

@brandondees @tmornini PERFECT example of the spec being changed (which now breaks our implementation theoretically). This would be a nightmare for us 1 year from now. Luckily we didn't expose CustomElement.upgrade (element) but internally we will need to implement this algorithm. @brandondees feel like making a issue here? Dunno what to call it as it's not really a bug but will be in the future.

Issue Request from W3C: https://github.com/w3c/webcomponents/issues/710 PR Response from WHATWG: https://github.com/whatwg/html/pull/3535 LOC in question (@tmornini when you're TOO good at #CATAT Call A Thing A Thing): https://github.com/devpunks/snuggsi/blame/master/custom-element-registry/index.es#L32 Tests to pass: https://github.com/w3c/web-platform-tests/pull/9869 Browser Bugs they are now forced to implement ASAP: https://github.com/whatwg/html/pull/3535#issuecomment-371027490

We got time before the browsers get there LOLZ but doesn't mean we can't implement today.

P.S. @brandondees still steering CLEAR AWAY from Shadow DOMmy stuff. YAGNI (yet). We support <slot> tho. Please respond with an issue not comment on unrelated PR that's becomming long in the tooth if not merged this week hehe.

/cc @tmornini

snuggs commented 6 years ago

In defense of .js

@brandondees we'll need to update Koa, (at minimum), Rails, Sinatra, Express, for the new .mjs and existing .es extensions. Many servers respond with application/octetstream for .mjs and .es. This is problematic and causes a Content-Disposition due to the spec stating to NEVER run that media type (for obvious security reasons). Luckily we can just update the core libs for respective platforms and cure most of the (sane) frameworks in the meantime. Anything that prevents the downloading of these files.

This prevents people from linking to unpkg. As a band aid we create a .es.js file :shit: For example >>> http://unpkg.com/snuggsi/dist/snuggsi.min.es vs http://unpkg.com/snuggsi/dist/snuggsi.min.es.js

Same holds true for .mjs files. Therefore a TON of servers are "broken" with this feature/bug (including ourselves).

I'm on it this weekend. This list and Resource.assets will be just about it for this PR. https://snuggsi.es can be active then and unpkg.com will work properly for people migrating to JS modules which will be very shortly here. Lastly, web/WHATWG/W3C/IETF/HTML/Fetch/DOM specs are fairly in order as media types have been an ancient πŸ’© show for about a decade now.

@tmornini may need your guidance on the protocol to update golang source code. text/x-javascript is on the MUST NOT USE list as far as the platform is concerned. What should we do to notify them? https://golang.org/src/mime/type.go

Related

References

ES6 Modules & Client/Server support

Anyone touching an app in the browser should at least get familiar. /cc @mrbernnz @btakita @halorium @janz93 @pachonk @robcole @scottmacdowell @kurtcagle @johnrlive

snuggs commented 6 years ago

@brandondees @tmornini irony. At the WHATWG/W3C we've come to consensus that the defacto mime for JS is text/javascript However, in Ruby, Node, and I believe Go the main mime libraries do not reflect for text/javascript (But do wrongly assume application/javascript as the old spec from 2003 that we are updating has always lead devs down the wrong mimetype path (pun intended).

So the last remaining tests in suite are failing until this bug/feature gets added.

capture d ecran 2018-06-06 a 14 15 09

snuggs commented 6 years ago

@tmornini as per your recommendation to skip for time being. Have created issue #174 to track progress.

Addressed in 00dc115

I think that's a wrap!!

Please accept.

tmornini commented 6 years ago

@tmornini may need your guidance on the protocol to update golang source code. text/x-javascript is on the MUST NOT USE list as far as the platform is concerned. What should we do to notify them? https://golang.org/src/mime/type.go

https://github.com/golang/go/issues