Closed madeleineostoja closed 7 years ago
This looks good, and yes to the two questions.
Cool. And one other thing on webcomponents.js - I'd actually say not include it as a dep at all, and in docs/snippets just link from cdnjs. Those more familiar with WC can always install w/ Bower themselves if they like (it's not available on NPM, and it's js... Srsly google why).
Cool, don't think I've got any issues with that. I'm always keen on polyfills separate - FWIW see this issue on polyfill.io service, though don't think anyone's gonna do it anytime soon, I certainly don't have time for it. Plus that's for v1.
Nice! Well when that gets shipped we just change our docs and snippets to use polyfill.io over cdnjs.
And for the record I still think we should include minor polyfills (eg: promise and fetch) as part of our bundle. They're robust enough not to be an issue, and the extra bundle size is worth the usability improvement of not worrying about those sdk-specific reqs. I tend to think of that kind of thing as similar to including an ES5 build (esp If we do them with babel plugins anyway). WC is a different beast though.
Agreed. And I think that can potentially be mitigated by other builds which are 'pure' - but not worth stressing about right now
Note: this deprecation
Slim down usageMonitoring and rename to ping or similar - should literally be a 200 okay from the SDK, no need for sessions or elements?
Would break the 'use elements' project setup step on the simpla.io dashboard, in that it'd no longer auto-complete when elements have been used. ie: things like the 'steps left' notification bubble, collapsed completed steps, etc wouldn't work. Do we care about this?
The 'use elements' step on the setup screen is now activated when a project has had data fetched from it (or attempted to at least), which is done via the API content fetched service, not no longer the usage monitoring ping, so it'll all still work even without the element information.
Ah, awesome. And I assume that still gets hit when elements request a non-existent UID / 404 content?
Yup - it only gets set on the project on the first call to fetching content, whether the content is there yet or not
👍
Re: Polyfills, for fetch we'll use https://github.com/developit/unfetch rather than babel transform, because 500 bytes (!)
Right so tried removing the polyfills and using the babel transform-runtime
but rollup was having some funky errors with it (https://github.com/rollup/rollup-plugin-babel/issues/40). But they're not needed for deprecations anyway, that's an internal optimization, so can leave it for another time correct? Same with using unfetch instead of fetch.
Few things we should hard deprecate before shipping:
[x]
hideDefaultContent()
(default-content
hard deprecated in v2)[x]
hashTracking
(moved tosimpla-admin
)[x]
webcomponents.js
import - too fragile, include as bower/npm dep and tell users to include separately (or from cdnjs if we keep app.simpla.io CDN)[x] Slim down
usageMonitoring
and rename toping
or similar - should literally be a 200 okay from the SDK, no need for sessions or elements?[ ] Use Babel plugins over
core-js
polyfills? Nicer to have it as part of our transform, rather than separate deps. Also often lighter than polyfills[x] Can we move the
deprecatedConfig
tov2-compat
layer since it's just for elements?