profile
viewpoint

kaleidawave/islands 8

An example of Simplex noise with phaser to construct islands

kaleidawave/prism 6

Prism is a experimental compiler for building isomorphic web applications with web components

kaleidawave/Tasks 4

Program to manage tasks

kaleidawave/pywikipedia 3

UNMAINTAINED: The only python wikipedia package you will ever need

kaleidawave/github-repos-vue 2

Created with CodeSandbox

kaleidawave/simple-monogame 2

A simple monogame application that demonstrates some of the basics within 200 lines of C# code

kaleidawave/instagram-cli 1

Upload to instagram from the command line using nodejs

kaleidawave/project-gyro 1

A imgur clone

kaleidawave/project-manager 1

Python project manager and creator

kaleidawave/Aether.Physics2D 0

2D collision detection system.

startedHackerNews/API

started time in 8 hours

startedmandarineorg/mandarinets

started time in 9 hours

pull request commentoakserver/oak

Request isolated state with registerSource

Currently has issues around strong typing. I don't think ts supports something where calling a method adds properties to its generic type.

Could be possible by passing through the constructor rather than calling at runtime:

new Application({sources: [{prop: "someUrl", resolver: (ctx: Context) => ...])

Allowing a custom prop is great if you are writing a custom in house request state source but for using ones from other authors its not great. Following the above example though a provider could export a value of type {prop: string, resolver: (ctx: Context) => T}. Example usage:

import {UserSession} from "../some-3rd-party-session-library/mod.ts";

new Application({sources: [UserSession])

Not sure about defining getters to every request and what effect that has on performance. Tried to do a single object and make it work through this scoping but I don't think it is possible.

Also not sure about renaming ctx.state to ctx.applicationState and the breaking changes that may introduce. But there may be some confusion around ctx.state and ctx.requestState.

Naming and arrangement is also up in the air

kaleidawave

comment created time in 9 hours

PR opened oakserver/oak

Request isolated state with registerSource

Currently ctx.state is global and points to the same object across requests:

https://github.com/oakserver/oak/blob/7f1d17b54966b809f20ba7ed62020b02b5736016/context.ts#L90

This has problems: #249

The following is what I think the request state system should be:

const app = new Application();

app.addEventListener("listen", () => console.log("Live @ http://localhost:8000"));
app.registerSource("someUrl", (ctx) => "someUrl:" + ctx.request.url.toString());

app.use((ctx: Context) => {
    console.log("In app.use:", ctx.requestState.someUrl);
});

The following adds a new method onto Application called registerSource. It is used to register a function which resolves a value. In the above example the function returns the URL of the request. This value can be accessed through the new ctx.requestState. The first argument of app.registerSource is the name of the property that this value is accessed under.

The response of the resolver / function is cached and so is not recomputed across middleware

+37 -7

0 comment

2 changed files

pr created time in 9 hours

push eventkaleidawave/oak

kaleidawave

commit sha 3a5c667f8f1de7aa3cbb4f487594c66647aa8949

Rough implementation of app.registerSource and ctx.requestState

view details

push time in 9 hours

create barnchkaleidawave/oak

branch : request-state-feature

created branch time in 9 hours

delete branch kaleidawave/oak

delete branch : request-state-feature

delete time in 9 hours

create barnchkaleidawave/oak

branch : request-state-feature

created branch time in 10 hours

fork kaleidawave/oak

A middleware framework for Deno's net server 🐿️ 🦕

https://oakserver.github.io/oak/

fork in 10 hours

push eventkaleidawave/oak

kaleidawave

commit sha c396b867d43c310338507d2d7e973b97ad33f204

fix: set cookie maxAge in seconds (#237) Fixes #236

view details

Kitson Kelly

commit sha 0c59b27cde21633021efefc3105ce6402b32c2c8

Update to Deno 1.4.0, std 0.69.0, media_types 2.4.7

view details

Guillaume Esquevin

commit sha 7df0e23905d390b5cc49ec852db8751b6836f355

Specify `import type` when applicable (#244) This fixes TS1371 that raises in deno 1.4.0 with the --unstable flag Deno typescript check is getting stricter by default: https://deno.land/manual/getting_started/typescript Co-authored-by: Guillaume Esquevin <gesquevin@csod.com>

view details

Kitson Kelly

commit sha e117fee791f5d8dbda73df0c4c27c441143f0aaa

Update to Deno 1.4.2, std 0.71.0, media_types 2.5.0

view details

Luca Casonato

commit sha 7f1d17b54966b809f20ba7ed62020b02b5736016

Update to Deno 1.4.4, std 0.73.0, media_types 2.5.1 (#247)

view details

kaleidawave

commit sha 1a79ad901d4be77b6f9d50d127e39b7520b5c9e3

Merge branch 'main' of https://github.com/kaleidawave/oak into main

view details

push time in 10 hours

push eventkaleidawave/oak

kaleidawave

commit sha ed47c31a0b97997d809935a9c30dafcb1048af58

Rough proposal of ctx.requestState and app.registerSource

view details

push time in 11 hours

create barnchkaleidawave/oak

branch : request-state-feature

created branch time in 11 hours

push eventkaleidawave/oak

Kitson Kelly

commit sha 2f6289c050daf67dd4529dc6aaac1424dffcb218

Update to Deno 1.4.0, std 0.69.0, media_types 2.4.7

view details

Guillaume Esquevin

commit sha aea944d40623f08870c34fc558b7da91aaebb21b

Specify `import type` when applicable (#244) This fixes TS1371 that raises in deno 1.4.0 with the --unstable flag Deno typescript check is getting stricter by default: https://deno.land/manual/getting_started/typescript Co-authored-by: Guillaume Esquevin <gesquevin@csod.com>

view details

Kitson Kelly

commit sha 4c94f194f75032e78cdccc8a806eceafb8972531

Update to Deno 1.4.2, std 0.71.0, media_types 2.5.0

view details

Luca Casonato

commit sha 7674beba836f428f3da4a80a0001e42da364b15d

Update to Deno 1.4.4, std 0.73.0, media_types 2.5.1 (#247)

view details

push time in 11 hours

PR merged kaleidawave/oak

Update main

Forgot to do last changes on a different branch

+122 -142

0 comment

43 changed files

kaleidawave

pr closed time in 11 hours

PR opened kaleidawave/oak

Update main

Forgot to do last changes on a different branch

+122 -142

0 comment

43 changed files

pr created time in 11 hours

issue openedkaleidawave/prism

Anchor tag point to page

Currently to do client side routing you must manually point to a URL and add the relative attribute.

It would better if rather than having to point at a URL that you could point at a page component instead.

<template>
    <a #to="SomeOtherPage">Go to SomeOtherPage</a>
</template>

<script>
     import {SomeOtherPage} from "./someOtherPage.prism";
     class SomePage extends Component {}
</script>

At compile time this would transform the #to to a href and add the client side routing events.

For pages with dynamic URLs e.g. /some/path/:x pointing to the page would a function call e.g.: #to="PathWithDynamicPath(this.data.x)"

This would strongly bind URLs to pages and remove the lookup/guesswork with hooking up URLs to pages. Importing the component would be necessary.

Should be fairly easy to implement. There may be some problems with cyclic #tos. Also pointing to the current page but under a different URL argument would require #21

created time in 18 hours

issue commentoakserver/oak

Authentication examples assumes all promises a resolved in request order

The problem is that its a design issue with Oak rather than a internal issue.

I'm in favor of re-purposing the ctx.state parameter to an object that's unique for every request, without the risk of leaking data between requests.

I believe this is already possible through just defining a property to request e.g. ctx.request["user"] = someUser. And I am not really sure how and where defaultRequestState would be useful.

At best it's a bug that's difficult to track down, because it only happens with requests happening in parallel. At worst, it's a gaping security hole allowing attackers to impersonate others.

👍

I would advocate for a registerSource method that exists on Application

const app = new Application();

app.registerSource<IUser>("user", (ctx) => getUserFromCTX(ctx));

app.use(async (ctx) => {
    console.log(ctx.requestState.user)
});

Under the hood it would add the method to some property on the application. The application would expose a object under ctx.requestState that is a bunch of getters that are created with Object.defineProperty. The value of this in the get execution would be ctx. And it would do the whole WeakMap thing under the hood. Kind of hard to describe, I will work on a PR in the next coming days to show it.

torsv454

comment created time in 19 hours

push eventkaleidawave/prism

kaleidawave

commit sha 5b7c8752253e39e2010a4b503ccaf0acbc8f523d

Added transpilation of ts interfaces (and type signatures) to Rust structs for server module compilation. Made a few changes to JS variable utils, added "use" ast structure and borrow operation

view details

push time in a day

startedsveltejs/hn.svelte.dev

started time in 2 days

push eventkaleidawave/prism

kaleidawave

commit sha 6feee6845632a142a6409e7a8ed2fd4cdb89004e

Added rust ast structures to chef, added string collapse to server render and started on creation of rust server modules

view details

push time in 2 days

push eventkaleidawave/prism

kaleidawave

commit sha 15233143fdfb82b963c819acc45d21a677af9d54

Reworked some chef apis - IValue -> ValueTypes - Statements -> StatementTypes

view details

push time in 2 days

push eventkaleidawave/prism

kaleidawave

commit sha 47ebc724bd6462b017847312b9e0f6d4ec2b414e

Abstracted server render expression result The result of compiling a node to be server rendered is non specific to a language (at templating level, expressions are still js ast nodes). Converted ts module compilation to accept this middle step. Renamed some chef interfaces

view details

push time in 3 days

PR opened kaleidawave/prism

Implement building Rust functions for server side rendering enhancement server-side-rendering
+459 -393

0 comment

27 changed files

pr created time in 4 days

push eventkaleidawave/prism

kaleidawave

commit sha 2a3745f78b9ebcd2bea8b2f42a8176a0950452c7

Started working on abstracting away from JS asts being the server render output - Isolated generation of ts module - Added abstract module that will apply to other language module types - Changes IStatement to be a union type. Not sure whether this helps anything - Made a bunch of properties public to Component bc of new isolated thing

view details

push time in 4 days

create barnchkaleidawave/prism

branch : rust-ssr-functions

created branch time in 4 days

issue openedkaleidawave/prism

Recursive components

Current you can use a component in a template with:

<template>
    <SomeComponent></SomeComponent>
</template>

<script>
    import {SomeComponent} from  "../../someComponent.prism";
   
    ...
</script>

And this works as long as SomeComponent is exported (prefixed with export keyword)

But there is no way of using the current component in a recursive way.

Using This could be a way of referring to the current component:

<template>
    <div #if="escapeLoop">
          <This></This>
    </div>
</template>

This should work as during client side as it will do this.append(document.createElement(**this component tag**) which is valid. It should work during server side rendering as it will do call the currently invoked function just like standard recursion

Just remember to add a exit condition 😋

created time in 5 days

startedactix/actix-web

started time in 5 days

push eventkaleidawave/prism

kaleidawave

commit sha d3b973a4281c40944c6f4722821ab374d6d86916

Fixes issues found in 1.2.0 - Absolute paths are now computed in settings as was having problems with getters - Exposed fs registration to node module users for if they don't want prism to hit there own fs - Moved some node specific stuff to node - Fixed variable shadowing (I think) - Fixed addEventListener("disabled") rather than removeAttribute("disabled") - Added some comments after build - Added further minifcation to runtime

view details

push time in 6 days

issue openedkaleidawave/prism

Build out full server (not just functions)

Currently Prism only outputs functions. And they can be imported so they can be used with a express or any other backend js framework to render body. e.g:

import {renderMainPage} from "../somePrismOutput/main-page.prism"

const app = express()

app.get("/", (req, res) => {
    res.send(renderMainPage(yourData))
});

This is great, you get the benefits of prism automating of synchronisation of client side render functions and server side render functions.

But Prism can do a little more here. It already knows what url routes to which pages. And its a compiler so its really good at generating code. So Prism could generate a whole express or oak application.

This could be implemented through a setting:

generateServer: "express" | "oak" | null

and the server runtime settings (port, hostname, ...) would be pulled in at runtime through process.env (or Deno.env.get(*)) or do defaults. It would compile in load callbacks of page components.

This would make it really simple to spin up a isomorphic project with Prism really quickly.

There is a bunch of things that would not be implemented. Things such as cookies, headers, separate server specific load functions and others. ands that's fine as this feature is not for building complex sites. It is just for getting a Prism app working on the server without having to manually build an express app to do so.

created time in 6 days

issue openedkaleidawave/prism

Compile server functions to other backend languages

Currently Prism compiles functions for rendering components and pages. These functions are built up of string concatenations so are incredibly simple and fast. These also feature string escaping etc... But they are very generic and simple to create as most of the work is done during templating.

But Prism only compiles these functions for JS engine use. Many other server side rendered sites use other backend languages such as golang, rust, ruby, python, c#, c++, ... . Which is a problem for building isomorphic sites as manually adding ssr templating desyncs the process of client side and server side views and templating. There are currently ways of calling JS code in golang and such and some have used that to achieve ssr of react apps. But as Prism is a compiler and there is not lot of complexity in the render functions I don't think it would be to hard to add the ability to output native golang, rust, ruby... functions for use with a backend framework.

This would be beneficial:

  • Enable isomorphic rendering for other languages that are used because they are the language currently used for a codebase or have packages that do not exist in the JS ecosystem
  • Enable isomorphic rendering for more performant languages to enable super fast ssr and reducing server latency and strain

Three current considerations:

  • Some languages have there own templating library/syntax would Prism compile to those? Golang has its own html templating language and C# has .cshtml. These seem to exist for DX, ease of use and compile time checking. However Prism offers all of this during compilation so they are not needed and add additional nuance. And prism output is designed to be run rather than analysed.
  • There is more that just syntax in the difference between programming languages This is very true. Functions, imports, string, concatenation and objects/structs exists in nearly every languages but actual runtime functions vary significantly in naming and existence. For example Intl.NumberFormat class does not exist in any other language in form or name. So sending it straight over to python would not work.

But there could be something like:

@returnValueIfUnderNonJSBackendLanguage(`f"{x:,.3f}"`)
function formatNumber(x: number) {
    return new Intl.NumberFormat('en').format(x)
]

That during ssr compile time could do some switching of the return expression ...

  • Interfaces / type definitions Currently if you build a Prism application with backendLanguage as ts it will include all the type information in the .ts server render function. (this works becomes of some specific things in chef and the fact ts is a superset of js. the ts info exists in the server module ast but is never rendered out...). It should be quite simple to transpile the interface ast (struct for golang and rust). Howerver actual data types do not exist across languages. This should be simple for some things like arrays. However types like number do not exactly map over. Whereas number exists in ecmascript, in rust there are u8, u16, i8, f64, .... and none of the quite match up. I think for this case it would be assume f64 and then you might have to do some casting when using this function. This problem is similar to the last point.

This does sound quite complex to implement but I think it would be quite simple. Just implement a fraction of syntax into chef (no parsing just render() methods) and add some step for transpilation. There would need to be a little work to implement the structure to build to non js based languages but once that is done then I think adding support for a language would be simple (especially after the first language support is implemented).

Implementing this would follow a common development characteristic of Prism where implement support for basic templating and add more complex templating later.

created time in 6 days

startedmilesj/packemon

started time in 6 days

issue closedkaleidawave/prism

Make compiler work on the browser

The several parts of the compiler that are locked to node runtime. Hopefully with some changes the compiler can span multiple contexts.

The are several parts of internal that were written quickly to get things working but now need to go back over to improve stabilty.

  • Isolate settings. Several parts rely on the global state of settings. This improve compiling multiple prism projects at once
  • Extend HTMLElement properties with a weak map rather than assigning to object (may have speed improvements)
  • Figure how to import runtime without fs (fetch???)
  • Figure how to configure TypeScript to target web

closed time in 7 days

kaleidawave

issue commentkaleidawave/prism

Make compiler work on the browser

Should be fixed with #18

kaleidawave

comment created time in 7 days

startedjozsefsallai/tbl

started time in 7 days

created tagkaleidawave/prism

tag1.2.0

Prism is a experimental compiler for building isomorphic web applications with web components

created time in 8 days

release kaleidawave/prism

1.2.0

released time in 8 days

push eventkaleidawave/prism

kaleidawave

commit sha d91d3e7b0bd21715f6ee9b4cdc4dc3bc3c156613

Moved aliasing of #if and #for expressions to client render and server render (the same way other aspects do so)

view details

push time in 8 days

push eventkaleidawave/prism

kaleidawave

commit sha 92a1fbb3e24d544f099179e33a5c048ee946e887

Fixes #15 - Dynamically removes unnecessary logic from runtime modules - Fixed issue where all nodes where marked as nullable - Minified some parameters in runtime functions manually - Added new tests for feature detection - Added some more examples (that are used for testing) - "getSettings" for render now "makeRenderSettings" and "getSettings" for unioning prism settings now "makePrismSettings" - Fixed comments setting - "ValueAspect" now "BindingAspect"

view details

push time in 8 days

issue closedkaleidawave/prism

Remove unused runtime library for component compilation

There is currently a bunch of code used at runtime that needs to be bundled for runtime to work. This includes things like the createObservableObject, the Component that every component extends and several other functions used for doing common runtime operations.

Runtime currently sits at around 4.34kb minified.

This is okay but there there are many large functions and methods that are only needed for #for and #if expressions. e.g createObservableArray.

This is okay for full apps build under prism compile-app that are likely to need all these features but for components built with prism compile-component that don't use #for or #if they may not be needed and will be more expensive to distribute.

I propose a model where under compile-component it sends a object to the construction of the component that if there are iterator and conditional expressions then will a flick a boolean switch. If switches are not true then some functions will be filtered out of the prism runtime bundle.

For very simple components this could reduce bundle by 1/2.

This is drastically more simple approach to tree shaking which works through code resolving references and automatically cut things out. Currently decent tree shaking is out of scope for chef

closed time in 8 days

kaleidawave

delete branch kaleidawave/prism

delete branch : internal-improvements

delete time in 9 days

push eventkaleidawave/prism

kaleidawave

commit sha 8ead12c1247b26eb9d5eb2a63c41d96997bd8b9f

Internal Improvements - Moved over to using WeakMap for extending elements with Prism syntax rather assigning property to HTMLElement instance - "clientRenderMethod" now reference to method - Improved way clientExpression nodes are handled during clientRender and serverRender - "Dependencies" now refered to as "bindings" - Settings are now not global and are designed to flow through processes - assignToObjectMap helper method for new data mapping process - Removed addAttribute function - getChildrenStatement renamed to getElement and now the only function for getting a expression to get reference to node - added "conditionalRoot" and "iteratorRoot" for definite source that it is #if or #for - adjusted tests for changes

view details

kaleidawave

commit sha 8a7261029cffedec8de2083c49da2c58545a3175

Added compat support for web - Added" tsc -p tsconfig.web.json && rollup -c" to build ts app with es6 module syntax then rollup to build single esmodule "web-out/bundle.js" that along with "web-out/bundle" enables the ability to compile Prism components on the browser - Adjusted a lot of internals to do node/browser branching for fs access - Added filesystem helpers to Prism and Chef which for browser contexts add the ability to register callbacks for doing fs access - Added hashbang for node parsing + some other changes to js tokenization - Removed some unused from helpers - Reconfigured settings flow - Small slot fix mistake from last commit

view details

kaleidawave

commit sha da2669dc2e66c6cd26665a06ec5fa283da0ea5fb

Internal changes - No longer include a bunch of files. Now uses inject-bundle.js to generate bundled-files during compiling source. Should be faster and better support for web - Removed compilation for web for now - Split some stuff. cli now entry of cli, node for using with node and web entry for web - FS read now async so had to change a few methods to work async. Currently does not capitalize on concurrency - Added flat map polyfill (in css/rules.ts) which now enables compilation under node 10

view details

kaleidawave

commit sha a8cd13b57325d8c56ce166f66f1239c4f7886478

Merge pull request #18 from kaleidawave/internal-improvements Internal improvements

view details

push time in 9 days

PR merged kaleidawave/prism

Internal improvements internals

Bunch of improvements internally. Doesn't fix any specific issues or add features. Should enable the ability to compile in the browser but haven't tested. Tidies some things to make future development easier and less error prone.

More in the commit descriptions but a summary:

  • Uses WeakMap rather than assigning to existing class instance
  • Change how filesystem is accessed to provide support for web
  • Bundled files are now compiled into src/bundled-files.ts at source build time
+1484 -1147

0 comment

48 changed files

kaleidawave

pr closed time in 9 days

PR opened kaleidawave/prism

Internal improvements internals

Bunch of improvements internally. Doesn't fix any specific issues or add features. Should enable the ability to compile in the browser but haven't tested. Tidies some things to make future development easier and less error prone.

More in the commit descriptions but a summary:

  • Uses WeakMap rather than assigning to existing class instance
  • Change how filesystem is accessed to provide support for web
  • Bundled files are now compiled into src/bundled-files.ts at source build time
+1484 -1147

0 comment

48 changed files

pr created time in 9 days

push eventkaleidawave/prism

kaleidawave

commit sha da2669dc2e66c6cd26665a06ec5fa283da0ea5fb

Internal changes - No longer include a bunch of files. Now uses inject-bundle.js to generate bundled-files during compiling source. Should be faster and better support for web - Removed compilation for web for now - Split some stuff. cli now entry of cli, node for using with node and web entry for web - FS read now async so had to change a few methods to work async. Currently does not capitalize on concurrency - Added flat map polyfill (in css/rules.ts) which now enables compilation under node 10

view details

push time in 9 days

issue commentoakserver/oak

Unable to catch HTTP exceptions.

It could maybe implemented as a opt in. I don't think it would be too hard to implement support for new Application({throwOnNotFound: true}) or something like that

andreespirela

comment created time in 10 days

issue commentoakserver/oak

Authentication examples assumes all promises a resolved in request order

I agree, storing request specific information to a single global variable is terrible. Especially for something as important as user sessions as your examples show a big security risk. I'm not sure if oak processes requests concurrently but that would cause problems with this method as well.

I am currently running oak with user sessions. The current JS best practise for associating data to an object is using WeakMap rather than assigning to its instance. This is something like I have currently:

const _ctxToUserIDMap: WeakMap<Context, string> = new WeakMap();

function getUserIDFromOakRequest(ctx: Context): string {
    if (_ctxToUserIDMap.has(ctx)) {
        return _ctxToUserIDMap.get(ctx);
    } else {
        const userID = /** get user id. as ctx is scoped you have access to its headers, cookies etc */
        _ctxToUserIDMap.set(ctx, userId);
        return userId;
    }
}

app.use((ctx: Context) => {
    const userID = getUserIDFromOakRequest(ctx);
    /** */
});

And this works because ctx is the same object throughout middleware (I think??). So what ever middleware is doing it can still get the user without going back to the databases etc. Using WeakMap rather than Map means that the ctx objects can be garbage collected. and this works with TypeScript. Prevents collisions with a possible other library that uses ctx.state.userID. And should be very fast by using maps. And the getUserIDFromOakRequest can be asynchronous. Just need to import and use this function where ever you need access to the user. And I can't see any concurrency or other problems here.

I think this is the model Oak should be pushing.

For now the example in the docs should be removed. and ctx.state should be renamed to ctx.appState to prevent confusion. @kitsonk

Deno and Oak are still not recommended for production so I don't this as a critical security issues.

torsv454

comment created time in 10 days

issue openedkaleidawave/prism

Value linked to object prop does not update if object is passed to another component

Given:

<SomeComponent data="someObj"></SomeComponent>
<h3>{someObj.username}</h3>

Executing:

***.data.someObj.username = "lorem-ipsum"

SomeComponent will see the updates and update its view but the text content of the h3 will stay the same.. This is because the component data tree references SomeComponents reactive data property under someObj and that reactive data tree is isolated to SomeComponent so it cannot bubble up changes to the main component.

This is quite a tricky one and one that prevents some uses cases. For now one could collapse SomeComponent into the others dom:

<div>
    <!--. .. -->
    <h2>{someObj.username}</h2>
    <!--. .. -->
</div>
<h3>{someObj.username}</h3>

To fix this there would likely be changes to observable.ts and the data reactivity compilation. It would have to know that the object prop is used twice, one in its own component DOM and also passed to another component. It could then wrap / proxy it and make sure the changes are done both in its own DOM and passing the update down to SomeComponent.

This would still have the issue that if SomeComponent changes its own username from inside, whether this should bubble up to the parent importer. This is not possible in React and why their context library. Not sure whether it would be a good feature but certainly possible under compilation.

There is also ways that #16 could help with this. Such as manual firing a method that could emit a event to the parent (importee) component so that it could update the h3 value...

created time in 10 days

issue openedkaleidawave/prism

@onGet and @onSet custom hooks

Currently there several types of bindings:

https://github.com/kaleidawave/prism/blob/9f76e8b7c3ebeaa811144cc5b587136d28d3bd1f/src/templating/template.ts#L50-L59

Currently set hook is not implemented. It would consist of adding a @onSet decorator to methods in the component class definition that would fire when the value parsed in as a argument is updated (the same way it works with updating the view via the DOM)

Example usage:

class SomeComponent extends Component<{title: string}> {
    @onSet(title)
    titleUpdate(value) {
        console.log("Title has updated to", value)
    }
}

Where value is the new updated value.

There could also be an opportunity for a @onGet decorator which would decorate a method that would return a value for manual server hydration. This could be used in places where Prism analysis for hydration fails. This would not be the same as a computed property. Once the hydration is needed and the @onGet method is fired and returns a value to the state then further gets to the property would return that in state rather than call the @onGet method again

created time in 10 days

startedcoreybutler/nvm-windows

started time in 10 days

startednvm-sh/nvm

started time in 10 days

push eventkaleidawave/prism

kaleidawave

commit sha 8a7261029cffedec8de2083c49da2c58545a3175

Added compat support for web - Added" tsc -p tsconfig.web.json && rollup -c" to build ts app with es6 module syntax then rollup to build single esmodule "web-out/bundle.js" that along with "web-out/bundle" enables the ability to compile Prism components on the browser - Adjusted a lot of internals to do node/browser branching for fs access - Added filesystem helpers to Prism and Chef which for browser contexts add the ability to register callbacks for doing fs access - Added hashbang for node parsing + some other changes to js tokenization - Removed some unused from helpers - Reconfigured settings flow - Small slot fix mistake from last commit

view details

push time in 10 days

startedcharmbracelet/glow

started time in 11 days

startedionic-team/rollup-plugin-node-polyfills

started time in 11 days

startedrollup/plugins

started time in 11 days

issue commentwebpack/webpack

How should we handle import.meta

Interesting, looks like webpack isn't for this project....

@evilebottnawi I would counter that:

Say I have /src/index.js:

console.log(import.meta.url)

And its webpack'd to /out/index.js. Then take some html file not compiled by webpack

<script type="module" src="/src/index.js?hello='x'"></script>
<script type="module" src="/out/index.js?hello='x'"></script>

Will log this:

> http://127.0.0.1:8080/src/index.js?hello=%27x%27
> file:///C:/Users/.../src/index.js

Unless I making the mistake that a webpack output is not to be used with non webpacked'd assets (as I need it to be) then it is not inline with the spec...

TheLarkInn

comment created time in 12 days

issue commentwebpack/webpack

How should we handle import.meta

@joeldenning Okay, but would that variable need to be set manually by everyone who uses the library...?

@evilebottnawi ok true but the problem is that 99% of this lib is not environment specific. There is ~2 sections (quite high up the call stack) that need to make fs calls. My current thinking is that at this point can split whether window is defined. The following should work if webpack doesn't change import.meta.url

/// <reference lib="dom"/>
import { join, dirname } from "path";

if (typeof window !== "undefined") {
    // @ts-ignore ts does not like during node compiliation `import.meta.url` 
    fetch(join(dirname(import.meta.url), "/bundle/x.txt"))
        .then(x => x.text())
        .then(x => console.log(x));
} else {
    console.log(require("fs").readFileSync(join(__dirname, "/bundle/x.txt")).toString());
}

Creating a branch of the library to not rely on fs calls is not possible. A solution would be to send down a function down that handles fs access and have separate web and node entry point where that function argument is different....? But I want to know why import.meta.url is compiled away as according to mdn it seems pretty dynamic....?

TheLarkInn

comment created time in 12 days

issue commentwebpack/webpack

How should we handle import.meta

Is there anyway to prevent webpack injecting to import.meta.url ??? Trying to dynamically fetch a required asset:

fetch(join(dirname(import.meta.url), "bundle/x.txt"))

Webpack compiles it to:

typeof window?fetch((0,e.join)((0,e.dirname)("file:///C:/Users/......./src/index.ts"),"bundle/x.txt"))

(I swapped part of the path with ....)

Which is completely useless. I don't know where this code is held so I can't compile away import.meta.url I only know that static asset x.txt will always be in the adjacent folder. I just want to leave it there untampered. Is it webpack or ts-loaded doing this???

TheLarkInn

comment created time in 12 days

startedducksoupdev/ficusjs

started time in 12 days

issue openedkaleidawave/prism

Remove unused runtime library for component compilation

There is currently a bunch of code used at runtime that needs to be bundled for runtime to work. This includes things like the createObservableObject, the Component that every component extends and several other functions used for doing common runtime operations.

Runtime currently sits at around 4.34kb minified.

This is okay but there there are many large functions and methods that are only needed for #for and #if expressions. e.g createObservableArray.

This is okay for full apps build under prism compile-app that are likely to need all these features but for components built with prism compile-component that don't use #for or #if they may not be needed and will be more expensive to distribute.

I propose a model where under compile-component it sends a object to the construction of the component that if there are iterator and conditional expressions then will a flick a boolean switch. If switches are not true then some functions will be filtered out of the prism runtime bundle.

For very simple components this could reduce bundle by 1/2.

This is drastically more simple approach to tree shaking which works through code resolving references and automatically cut things out. Currently decent tree shaking is out of scope for chef

created time in 12 days

startednippur72/ifdef-loader

started time in 12 days

create barnchkaleidawave/prism

branch : internal-improvements

created branch time in 12 days

issue openedkaleidawave/prism

Make compiler work on the browser

The several parts of the compiler that are locked to node runtime. Hopefully with some changes the compiler can span multiple contexts.

The are several parts of internal that were written quickly to get things working but now need to go back over to improve stabilty.

  • Isolate settings. Several parts rely on the global state of settings. This improve compiling multiple prism projects at once
  • Extend HTMLElement properties with a weak map rather than assigning to object (may have speed improvements)
  • Figure how to import runtime without fs (fetch???)
  • Figure how to configure TypeScript to target web

created time in 14 days

created tagkaleidawave/prism

tag1.1.0

Prism is a experimental compiler for building isomorphic web applications with web components

created time in 15 days

release kaleidawave/prism

1.1.0

released time in 15 days

issue openedkaleidawave/prism

SSR data parameter of layouts

Currently a layout component (Denoted with @Layout decorator) can have a state on the frontend. It inherits from Component and its markup is subject to the same templating binding and reactivity that any other component is subject to.

The problem arises around server side rendering pages that use a layout which has data. The component should append its inherited layout parameter to its own parameters.

Issue is around: https://github.com/kaleidawave/prism/blob/9f76e8b7c3ebeaa811144cc5b587136d28d3bd1f/src/component.ts#L677

There is also a opportunity here to refactor the way client global parameters work in the same way.

created time in 15 days

issue openedkaleidawave/prism

Bundle imports

Current imports are used for:

  • Importing Prism components so that templating is aware of custom tags
  • Importing @Globals for server
  • import type for the type resolving system

As of v1.0.2 Prism strips all imports and exports when bundling the whole application. This means that if you are importing a es module from another server then it will be removed.

Bundling is currently done via concatenating all <script>s in .prism definitions and .js and .ts files in the scripts folder of the assets path. Rather than via imports.

The stripping of imports and exports is done because effective code splitting is not quite worked out yet. And it over compensates by removing all imports as a bad static import would cause the script to not run.

And v1.0.2 is not a production build meant to integrate with other code. If importing is important then you can get away with dynamic imports.

Imports bundling and tree shaking are a bit out of the scope for chef rn so it would mean bringing webpack, rollup or other bundlers into the toolchain.

created time in 15 days

push eventkaleidawave/prism

kaleidawave

commit sha 9f76e8b7c3ebeaa811144cc5b587136d28d3bd1f

Added @NoSSRData and other small fixes - @NoSSRData decorator which will use the default data to render view under SSR rather than from a parameter - Fixed cjs export of interface under JS - Issue around trailing comments in interface

view details

push time in 15 days

issue openedkaleidawave/prism

Expression reversal

The idea behind Prism JIT hydration system is that as a compiler it knows where variables are interpolated and so can build ways to retrieve them and cache them into the components data / state.

The first step is the runtime knowing where in the DOM tree they are interpolated. Prism does this by adding identifiers to nodes and also what part they are interpolated at (attribute, text node etc). The compiler builds in these expressions in get-value.ts

And this is fine for simple templates:

<template>
    <div $data-x="varX"></div>
</template>

Compiler output:

getVarX() {
   return this.getElem(<prism generated id>).getAttribute("data-x")
}

The problem arises around more complex templates:

<template>
    <h1>
        {varX * 2}
    </h1>
</template>

Prism recognises that rendered output may not be 1:1 with rendered markup and there is a case for doing manipulation during templating. The problem is that unlike the previous scenario returning the text node data as a value for varX would incorrectly hydrate varX as being twice the value it is. A step is required to transform rendered output to original state through a reverse of what was done during interpolation.

Currently Prism has reversers for multiplication, division and template literals interpolation: reverse.ts

varX * 2 will divide the text content (relies on string casting to number) by 2. Division does the opposite. For simple template literals the following `Hello ${name}` will convert it into a slice expression.

This is an issue bigger than Prism:

For example attempting to produce a reverse expression for a + b (where a & b are numbers) is impossible. The rendered output may be 15 which could come from a = 3, b = 12 or a = 5, b = 10 etc.

There are other issues around text concatenation with multiple variables (Only for attributes, text node concatenation is fine as it is split up with comments). For example: `${x}a${y}`, if its rendered value is aaa then it is ambiguous whether the cases are x = "aa", y = "", x = "", y = "aa", or x = "a", y = "a".

There are some other very technical scenarios here around what if the x value is only hydrated to test if it begins with "b" or something where the ambiguity is okay. And there is a possibility that if you are ok with ambiguity there could be some regex here.

This is a common case around number and date formatting where the literal value is not there and it requires parsing to get the rendered version back to something looking like it was on the server.

Where this issue becomes very difficult is around non 1:1 mappings and expressions that involve more than one variable.

For now this can be solved by server rendering the data to $data-* attributes so the client has easy access to values. This will make payloads bigger unfortunately. (There is another issue here around not client side rendering these attributes or doing updates to them).

Types:

The other issue is that server nodes and attributes always return strings. This is a problem for properties than are numbers or Dates and at client runtime need to be of that type. This is one of the reasons for the generic data argument on Component. The type information parsed at compile time and will inject parseFloat or new Date() to properties that are of that type.

created time in 15 days

push eventkaleidawave/prism

kaleidawave

commit sha b958035b58eb75f8717d69c2af24bb0657b45a71

Fixed reversal of template literal + other small fixes - Tree variable assigned to class in component.ts rather than data-binding.ts - $data assignment to components null safe - PrefixIncrement / Decrement now renders - Replace variable fuzzy - Fixed js ast aliasing and cloning issues

view details

push time in 16 days

issue commentFiloSottile/mkcert

net::ERR_SSL_KEY_USAGE_INCOMPATIBLE

Also having this issue: image

romanpastu

comment created time in 17 days

push eventkaleidawave/prism

kaleidawave

commit sha 7ef5a1c1291f882c02684a389cf8a34ef0d01bea

Small fixes to #for under conditional nodes - getChildrenStatement now includes optional indexing and chaining for nullable root elements - setLength null safe - append is now null safe - Removed new lines around fragment comments that lead to whitespace issues

view details

push time in 17 days

issue openedkaleidawave/prism

Lookup of non server rendered data

(not really a issue but something tools that explicitly send down the entire state as an object don't encounter)

So given this template:

<template>
    <div #if="someX">
        <h1>{someY}</h1>
    </div>
</template>

If the template is rendered with the state of someX === false the h1 below will not be rendered and sent to the client. This is a little bit of a problem as if this.data.someY is called it will be null but when the server rendered it may have had a value.

Two fixes for if it is important that someY needs to be accessed at runtime:

1: Use $hidden:
<template>
    <div $hidden="someX">
        <h1>{someY}</h1>
    </div>
</template>

This will still be sent to the client and accessible from the DOM but have the effect of not being visible by the user. It someX is very likely to change at runtime this is a good way to go as it can be instantly revealed rather than the tree being generated on the client. However if someX is hardly ever changed or never changed and the tree under it is large it will end up with a lot of extraneous html.

2: Put the value elsewhere:
<template>
    <div $data-some-y="someY"></div>
    <div $hidden="someX">
        <h1>{someY}</h1>
    </div>
</template>

This way someY is still sent to the client un conditionally. Bad if someX is often truthy and someY is sent twice, especially is someY is large.

created time in 17 days

issue openedkaleidawave/prism

Reassignment after rendering conditional element / array item rendered twice

Given the following template:

<template>
    <div #if="someString !== 'x'">
        {someString}
    </div>
</template>

Let someString equal 'x' initially.

If someString is reassigned to "abc" then at runtime:

  1. someString !== 'x' is now truthy so the div is rendered with the state (this.data equal to) {someString: "abc"} and swapped in for a placeholder element
  2. someString value has changed so it tries to set the first text node of the div (if it exists) content to "abc"

The problem is when the render of the div occurs it will render in with the updated state so it will have "abc" as its text content. Therefore the second call is redundant for this update. However a second assign to someString of "xyz" requires the second statement, as the update would not be reflected on the view as the render of the div and swap would not occur.

This isn't a big deal here, no bad effects only additional calls with no effect which could be a perf problem.

However for:

<template>
    <div #if="someArr.length > 3">
        <ul #for="const x of someArr">
             <li>{x}</li>
        </ul>
    </div>
</template>

.pushing to someArr while someArr.length === 3 will cause the argument of push to be in the ul list twice. Once from initial render when someArr.length > 3 becomes truthy and second when the push call means assigning to a index outside of current length causing a new li to be rendered.

There are some mitigations such as maintaining a separate prop for the condition as not to clash with variables used inside and controlling that prop manually.

But there is definitely some ways the compiler could see this problem occurring and generate code for mitigations.

created time in 17 days

push eventkaleidawave/prism

kaleidawave

commit sha 4aff4a99f76ceb0e449c870a0e84098b718292a5

Small fixes - Typo in get-value from prev commit - Template shell written under context=isomorphic for sw reasons - Non bundled scripts and styles are now interpreted (ts removal, nested css comp, minifcation)

view details

push time in 19 days

issue openedkaleidawave/prism

Pass single props to components

Currently to send data to a object the only supported method is through sending a whole already existing object to a component:

<SomeComponent $data="someObj"></SomeComponent>

This works fine through csr, ssr and cssu (client side state updates).

It would be nice if rather than having to send a whole object that it could be constructed from state:

<SomeComponent $data="{someProp: x}"></SomeComponent>
<SomeComponent $data="{...someObj, someProp: x}"></SomeComponent>

This should currently work with csr and ssr. It just takes a few additions to the set and get compiler logic to work. But there may be some nuances with reference types...?

There is then the opportunity to add more intuitive syntax for this:

<SomeComponent $data-someProp="x"></SomeComponent>
<!-- To be desugared to: -->
<SomeComponent $data="{someProp: x}"></SomeComponent>

created time in 19 days

push eventkaleidawave/prism

kaleidawave

commit sha d277f953017cc10048e5b26c8ae255519fccf2b9

Fixes #7 and some changes to VariableReference.fromChain

view details

push time in 19 days

issue closedkaleidawave/prism

Text interpolation reactivity throws when under un rendered element

Given the following template:

<template>
    <div #if="someX">
        {someY}
    </div>
</template>

Attempting to set someY while someX is falsy will throw as the div is not rendered and thus *div*.childNodes[0].data is undefined and cannot be assigned to.

The compile is aware the element "nullable" and thus should generate code that checks can do update before trying to assign to undefined and throwing.

There is a lot of edge cases and other issues around "nullable" elements and there may be a better solution to this later but for now a patch to prevent the throw and the disruption to later execution is required

closed time in 19 days

kaleidawave

startedprisma/prisma-client-go

started time in 19 days

issue openedkaleidawave/prism

Text interpolation reactivity throws

Given the following template:

<template>
    <div #if="someX">
        {someY}
    </div>
</template>

Attempting to set someY while someX is falsy will throw as the div is not rendered and thus *div*.childNodes[0].data is undefined and cannot be assigned to.

The compile is aware the element "nullable" and thus should generate code that checks can do update before trying to assign to undefined and throwing.

There is a lot of edge cases and other issues around "nullable" elements and there may be a better solution to this later but for now a patch to prevent the throw and the disruption to later execution is required

created time in 20 days

startedshayne/go-wsl2-host

started time in 20 days

push eventkaleidawave/prism

kaleidawave

commit sha fa92d114662453cd672e59d31a801b39b2bca5ab

Fixes #6 + "/" not being valid in dynamic url argument

view details

push time in 20 days

issue closedkaleidawave/prism

Allow page to match on multiple route patterns

It would be cool if the @Page decorator could have multiple arguments for each URL pattern it matches on.

e.g.

@Page("*", "/error")
@Page("/upload", "/upload-post")

Should be quite simple, just repeat the entry on Router.routes with a different regexp

closed time in 20 days

kaleidawave

issue openedkaleidawave/prism

Allow page to match on multiple route patterns

It would be cool if the @Page decorator could have multiple arguments for each URL pattern it matches on.

e.g.

@Page("*", "/error")
@Page("/upload", "/upload-post")

Should be quite simple, just repeat the entry on Router.routes with a different regexp

created time in 20 days

delete branch kaleidawave/prism

delete branch : type-fixes

delete time in 21 days

push eventkaleidawave/prism

kaleidawave

commit sha f0f9d52081c0058cae21824a843f7fd43f7659de

Fixes #1 and fixes #2

view details

kaleidawave

commit sha 1b91cf0454964c2481ff1373d30bd0668f5c76ac

Fixes #3 and fixes #4

view details

kaleidawave

commit sha 8cf90d0df195cfbf764cc44d457db19669c6c7e8

Merge pull request #5 from kaleidawave/type-fixes Type fixes

view details

push time in 21 days

issue closedkaleidawave/prism

Type resolver does not recognise enums

Given a enum in the module trying to resolve the properties of that type throws a error: Error: Could not find type: X in module

const mod = Module.fromString(`enum X { A, B }`);
console.log(typeSignatureToIType(new TypeSignature("X"), mod));

typeSignatureToIType should return enums to be of type number (or string). Think that is good enough

closed time in 21 days

kaleidawave

issue closedkaleidawave/prism

Render out enum under JavaScript

Currently rendering out any Enum with settings.scriptLanguage === ScriptLanguages.Javascript will throw:

https://github.com/kaleidawave/prism/blob/92dd5d94d167b7708e8ea739d78195fe88693e26/src/chef/javascript/components/types/enum.ts#L31-L32

Chef should instead create a temp object literal and render that out instead if rendering out Javascript. Object should preferable be frozen to prevent runtime mutation. I think this is also the tsc implementation.

This wouldn't fix const enums as they require more that just rendering additional js

closed time in 21 days

kaleidawave

issue closedkaleidawave/prism

Implement intersection types

On trying to parse a type signature with a intersection type it throws ParseError: Expected "End of script" received "&".

Example:

const bDeclaration = VariableDeclaration.fromString(`let b: a & b;`);

closed time in 21 days

kaleidawave

issue closedkaleidawave/prism

Literal types being interpreted as actual type

Currently chef interprets literal types as being actual types.

> const bDeclaration = VariableDeclaration.fromString(`const b: "abc" = "abc";`);
> bDeclartion
> TypeSignature { name: "abc" }

Which causes them to be rendered without quotations:

> bDeclaration.render(getSettings({scriptLanguage: ScriptLanguages.Typescript}))
> const b: abc = "abc";

Literal types (strings, numbers and booleans) should be recognised in TypeSignature as a Value and parsed accordingly

closed time in 21 days

kaleidawave

PR merged kaleidawave/prism

Type fixes bug chef/javascript enhancement

Fixes issues #1, #2, #3, #4

  • Fixes string and number literal types
  • Implements intersection types
  • Renders out ts enums as js objects for compat
  • Enums are now resolved to be number or string types

Should allow for use of enum use in prism templates.

+199 -33

0 comment

8 changed files

kaleidawave

pr closed time in 21 days

PR opened kaleidawave/prism

Type fixes bug chef/javascript enhancement

Fixes issues #1, #2, #3, #4

  • Fixes string and number literal types
  • Implements intersection types
  • Renders out ts enums as js objects for compat
  • Enums are now resolved to be number or string types

Should allow for use of enum use in prism templates.

+199 -33

0 comment

8 changed files

pr created time in 21 days

push eventkaleidawave/prism

kaleidawave

commit sha 1b91cf0454964c2481ff1373d30bd0668f5c76ac

Fixes #3 and fixes #4

view details

push time in 21 days

issue openedkaleidawave/prism

Type resolver does not recognise enums

Given a enum in the module trying to resolve the properties of that type throws a error: Error: Could not find type: X in module

const mod = Module.fromString(`enum X { A, B }`);
console.log(typeSignatureToIType(new TypeSignature("X"), mod));

typeSignatureToIType should return enums to be of type number (or string). Think that is good enough

created time in 21 days

startedboa-dev/boa

started time in 21 days

issue openedkaleidawave/prism

Render out enum under JavaScript

Currently rendering out any Enum with settings.scriptLanguage === ScriptLanguages.Javascript will throw:

https://github.com/kaleidawave/prism/blob/92dd5d94d167b7708e8ea739d78195fe88693e26/src/chef/javascript/components/types/enum.ts#L31-L32

Chef should instead create a temp object literal and render that out instead if rendering out Javascript. Object should preferable be frozen to prevent runtime mutation. I think this is also the tsc implementation.

This wouldn't fix const enums as they require more that just rendering additional js

created time in 21 days

create barnchkaleidawave/prism

branch : type-fixes

created branch time in 21 days

issue commentoakserver/oak

Run application failed with Deno version: 1.0.0 on Ubuntu 20.04.1 LTS (Focal Fossa) (WSL2)

Likely because old version of deno. Try deno upgrade and run again

SomboChea

comment created time in 22 days

issue openedkaleidawave/prism

Implement intersection types

On trying to parse a type signature with a intersection type it throws ParseError: Expected "End of script" received "&".

Example:

const bDeclaration = VariableDeclaration.fromString(`let b: a & b;`);

created time in 22 days

issue openedkaleidawave/prism

Literal types being interpreted as actual type

Currently chef interprets literal types as being actual types.

> const bDeclaration = VariableDeclaration.fromString(`const b: "abc" = "abc";`);
> bDeclartion
> TypeSignature { name: "abc" }

Which causes them to be rendered without quotations:

> bDeclaration.render(getSettings({scriptLanguage: ScriptLanguages.Typescript}))
> const b: abc = "abc";

Literal types (strings, numbers and booleans) should be recognised in TypeSignature as a Value and parsed accordingly

created time in 22 days

created tagkaleidawave/prism

tag1.0.2

Prism is a experimental compile for building isomorphic web applications with web components

created time in 22 days

more