Conversation
src/styling/CSSTemplate.ts
Outdated
| @@ -1,3 +1,5 @@ | |||
| import "../globalTypes/CSSStyleSheet.ts" | |||
There was a problem hiding this comment.
Apparently import type is not supported without importing something specific. However, the way it is in its current form is not ideal, because it'll be importing this file even at runtime if it's not a type import.
There was a problem hiding this comment.
This is more a way around using a globalThis.d.ts - it's just to include that type in the global scope
Saying this, where does it mention replace exists on CSSStyleSheet? Not the one ou define, but I remember you saying that the lib doesn't have it defined (yet) but it does exist, or something along those lines?
There was a problem hiding this comment.
Saying this, where does it mention
replaceexists onCSSStyleSheet? Not the one ou define, but I remember you saying that the lib doesn't have it defined (yet) but it does exist, or something along those lines?
Here's the MDN page and here's some additional documentation.
There was a problem hiding this comment.
The problem with import "./path" is that it shows up in the final compiled output, which is why type-only imports need to be imported with import type to avoid there being extraneous junk in the output.
There was a problem hiding this comment.
Ok gotcha, looked through the code and can understand this better
I don't think importing it as a type is a possibility, and if you wanna avoid junk then i think the next best thing would be slapping a ts ignore on it :/ But ill keep thinking
There was a problem hiding this comment.
Or another 'hack' would be modifying that global type file to just export an interface, and do something like:
// globaltypes/cssstylesheet.ts
export intrface ICSSStyleSheet extends CSSStyleSheet {
replace: (css: string) => void
}
// styling/CSSTemplate.ts
import type { ICSSStyleSheet } from ...
...
(this.#stylehsheet as ICSSStyleSheet).replace(this.cssText)There was a problem hiding this comment.
or do #stylesheet: ICSSStyleSheet | undefined instead (keeping the interface we import too)
There was a problem hiding this comment.
Seems like doing the cast might be the least bad option.
ebebbington
left a comment
There was a problem hiding this comment.
formatting wasn't part of the project before, so remove this
package.json
Outdated
| "lint:code": "eslint src", | ||
| "lint:types": "tsc --noEmit", | ||
| "lint": "deno lint --ignore=dist", | ||
| "fmt": "deno fmt --ignore=dist", |
There was a problem hiding this comment.
Don't remove it yet, I'll have a look at what it looks like and see if it's useful to keep once I get some time.
|
Love the latest commit message lol. |
examples/.gitignore
Outdated
| @@ -0,0 +1,3 @@ | |||
| node/package-lock.json | |||
There was a problem hiding this comment.
Purely making a note here so I remember to remove the examples directory - would be great if we could turn these into tutorials :)
There was a problem hiding this comment.
Yeah honestly the examples don't make a ton of sense as part of the lib core, but that's where I run the tests, so I don't know if it's feasible to remove the examples completely 😬
There was a problem hiding this comment.
It was more to help both us understand if it works for each environment :) After all we could turn the 'setups' into written tutorials
though i see what you mean...might be worth something to you, just maybe there's a better place to put these directories?
There was a problem hiding this comment.
I might've actually misunderstood what you meant, my bad. Ignore my previous comment.
There was a problem hiding this comment.
resolving, pr desc now includes a note about this
|
as of now, using canary (> 1.11.5) the infinite loop has gone, but revealed some more issues: |
|
3647b7f does address both issues mentioned above, though of course it is a tiny workaround |
Could've just moved the cleanup method outside the class, since it's doing nothing with the instance anyway. |
Guess that's your preferred way then :P Is this approach something you're ok with? |
src/examples_mod.ts
Outdated
| // Import some example files that aren't included in the dependency free, so we can compile them | ||
| import "./_examples/main.ts" | ||
| import "./_examples/components/visitor-demo.ts" | ||
| import "./_examples/components/to-do/_to-do.ts" | ||
| import "./_examples/components/array-demo.ts" | ||
| import "./_examples/components/time-diff.ts" | ||
| import "./_examples/components/async-demo.ts" | ||
| import "./_examples/components/window-manager/_window-manager.ts" No newline at end of file |
There was a problem hiding this comment.
Note about this file that i want to mention:
If instead of setting the path to the js file inside the tab-view.ts, we imported the class and passed it in, we wouldn't need the examples_mod.ts file, and would only need to emit _examples/main.ts, so for example:
// src/_examples/components/tab-view.ts
import { AllComponents } from "all the files we need"
class TabView {
#tabs = [
{
url: "/array-demo",
component: ArrayDemo // before, it would be "./components/array-demo.js"
}
]
}Of course the hash router would need to account for this.
Curious on your thoughts @0kku?
There was a problem hiding this comment.
That would make it into a static import. It's intentionally dynamic: the component is not loaded until the user clicks on the tab. This makes initial load faster and avoids loading a potentially substantial number of pages that the user wasn't interested in visiting anyway. It's not a big deal on the example page because it's very small, but it's an example on how to do code splitting for a large website that could potentially have hundreds of large pages.
Many changes:
deno fmtis availablecompile.tsfile, in place of tsc, which uses 2 unstable api's.tsextensions to imports forsrcinstead of.js(to pass emit checks)examples_mod.tsinsidesrcso we can properly emit the examples. Reason for this is, they aren't part of the dependency free formod.tsso aren't included in the emit result. Due to this, we compileexamples_mod.tstoo. Not worth compiling each individual file instead because that takes a long time. As it stands, runningcompile.tsis faster than tsc/webpackOf course it's completely down to you @0kku, as to whether you want to request changes, let along approve this PR, it's all welcomed and i completely understand
So how do you, Okku, and an end user use destiny now?
Good question edward
As the maintainer of Destiny, you would:
src/*.tsfiles finenpm run compileand deploy as you usually would this generates maps, declaration files and js files, so you can import it in the browser for js filesAs a user of Destiny:
TODO