A completely customizable framework for building rich text editors. (Currently in beta.)
A simple and composable way to validate data in JavaScript (and TypeScript).
An unopinionated authentication library for building Node.js APIs.
A CSS preprocessor that acts like a polyfill for future versions of the spec.
So that you can have an animated sketch paused, but inch forward a frame at a time.
Potentially even a shift and option+shift variants like in design programs to jump 10 or 60 frames forward as well.
Right now if you import
an local file (instead of a dependency) it doesn't get picked up by the reloading service, so nothing new is built. This is due to esbuild
not having bundle: true
specified for it's watcher.
When an error happens and then you edit and save and live-reload, right now the error popups stays there sometimes, despite the sketch working again.
Very cool idea, I'd be open to a pull request that implements this! Feel free to talk through the implementation here too to see if it will work or what the gotchas might be.
@mmaietta that would be awesome! As soon as the holidays are over I'm happy to test it out.
Hey @graveljp thanks for taking the time to write that up. That makes total sense on the reasoning for why it's designed the way it is. For actual layering I'd probably use multiple canvases stacked on top of each other.
I think my point is mostly about naming. Using the "layer" in the name is likely going to require every explanation of the concept to be prefaced by something like:
Note that the
beginLayer
/endLayer
methods don't deal with layers in the traditional graphics editor sense, but are instead used to compose blending modes and filters.
(If you search "html canvas layers" you'll see lots of results all trying to solve the familiar problem of layering with canvas.)
So I'd suggest using a different naming scheme that avoids that confusion. Something like beginComposition
, beginCompose
, beginBlend
, beginFilter
, or some other name I'm not knowledgeable enough to know of.
Amazing, thank you @evanw! Totally makes sense about needing null
when the original source isn’t in the filesystem at all.
Right now it restarts the sketch, but it should really just toggle the visibility of the DOM element instead. For static sketches it's equivalent, but for animations the current behavior is tedious.
This isn't technically a current problem, but it will be whenever the package updates its internal martinez-polygon-clipping
dependency.
I had a setup where I was accidentally leaving the martinez-polygon-clipping
dependency unpegged and it was importing the newest ~0.7
version and returning weird outputs with non-conforming polygon arrays when union
was called internally. I'd end up with a return value of:
[
[number, number][],
[number, number],
[number, number],
[number, number],
[number, number],
...
]
Instead of:
[number, number][][]
And it took me forever to track down that the internal dependency was unpegged.
Anyways, not a current issue, but it seems like the jump from martinez@0.1
to martinez@0.7
might break things.
Also, just for clarity, this isn't a TypeScript-specific problem. Any dependency that is bundled with its own source map that omits the sourcesContent
has the same result.
For example, the simplex-noise
package references its source map which doesn't have sourcesContent
. And this will show up as null
after bundling too.
Because the entrypoint server is really simple currently, and just serves sketch.js
and sketch.js.map
, if any of the imported packages in a sketch don't include their sourceContent
inline in the sourcemap, they won't be able to be loaded by devtools.
In TypeScript a third-party package can make its source content inlined by setting…
{
"sourceMap": true,
"inlineSourceMap": true,
}
…but many won't have done that.
Ideally either the server could serve all files (need to check if this is secure first though). Or the single sourcemap could get all of its source files's content inlined, and its JSON can be updated with the new source content strings before serving.
If a dependency uses is compiled with TypeScript and forgets to set inlineSourceContent: true
(which seems like the default?), then it will result in a null
entry in the source map's sourceContent
array.
If you're bundling your output into a single file and serving that single file with its sourcemap inline (so that it's all contained in one place), then Chrome Devtools will fail when you try to step in to the source of that dependency with Could not load content for …
because of the null
value in the source content array.
I understand situations where you'd want to have all source content omitted with the sourceContent: false
option to save space. But when sourceContent: true
is set, is there ever a case where you'd want null
entries? Wouldn't it be better if esbuild inlined the source content itself if it was missing in the upstream package? (Or potentially as a separate 'inline'
setting?)
I might be missing something since source maps are a little cryptic. If so I apologize.
But my use case was essentially hoping to bundle everything into a single file, with all source information included inline, so that no external requests are needed to provide full debugging abilities.
Right now it gets clipped off…
If you export an animation it replays the whole thing to export it, so it can take a while, so we need a little indicator showing the frame ticking by so you know how long it will take.
So you can programmatically stop a sketch that is underway.
Not sure what's going on, but something with the Electron auto-updated isn't configured properly. If you press "Restart" when an update is ready, it won't relaunch and when you manually launch it errors.
If you don't supply a step
it will print always with 3 decimal places, which is janky for values like 1.5
which get rendered at 1.500
. Should get rid of the unnecessary zeroes in those cases.
For animations. I'll often want to pause at a certain frame, or even just to hit stop to save CPU while going to edit the code for a bit.
I'm curious about why the naming uses "layers" as a concept with beginLayer/endLayer
, instead of calling them simply beginFilter/endFilter
if their sole purpose is to be able to apply filters to groups of commands. Because I excepted "layers" to be something else, more analogous to layers in a graphics editor that can be shown/hidden/reordered/etc.
update demo link and screenshot