Consider "external core" Feather Wiki #113

Open
opened 2023-07-15 15:04:17 +00:00 by sbaird · 2 comments

What's your idea?

With TiddlyWiki it's possible to load all the static javascript with script tag.

(For an example look at view-source:https://mptw5x.tiddlyhost.com/ ).

Could Feather Wiki work like that also? Would be easy to build an "external core edition"?

Is your idea trying to solve a specific problem?

Nah, just thinking about it. FeatherWiki is already tiny, but I'm curious about the idea of a Tiddlyhost save being just a few bytes of data.

Additional context

Might need to think of a new bird name.. :D

## What's your idea? With TiddlyWiki it's possible to load all the static javascript with script tag. (For an example look at view-source:https://mptw5x.tiddlyhost.com/ ). Could Feather Wiki work like that also? Would be easy to build an "external core edition"? ### Is your idea trying to solve a specific problem? Nah, just thinking about it. FeatherWiki is already tiny, but I'm curious about the idea of a Tiddlyhost save being just a few bytes of data. ### Additional context Might need to think of a new bird name.. :D
sbaird added the
request
label 2023-07-15 15:04:18 +00:00
Alamantus added the
enhancement
label 2023-07-31 15:35:20 +00:00

Hey @sbaird, I love this idea, and it should be super easy to add to the project since the build process already splits out the CSS and JS separately in order to inject it into the HTML! I can very easily just include those files in the Builds folder. The only drawback that I foresee could trip up anyone using it is the fact that the Custom Head content is both stored in the content JSON and injected into the HTML when saving because I couldn't figure out a reliable way to always grab the correct HTML from the head.

When using the external core, you'll have to make sure to manually inject the Custom Head content into the HTML. Within the Feather Wiki code, this is done using FW.inject.esc(p.head, true) directly before </head> in the HTML, where p is the un-minified content normally stored in <script id=p type=application/json> on the HTML output (found in FW.state.p when loaded).

Do you think that's okay/manageable?

Also, the JS would almost certainly be called "Feather Wiki Skeleton" and the CSS would be something like "Feather Wiki Plumage" 😄

Hey @sbaird, I love this idea, and it should be super easy to add to the project since the build process already splits out the CSS and JS separately in order to inject it into the HTML! I can very easily just include those files in the Builds folder. The only drawback that I foresee could trip up anyone using it is the fact that the **Custom Head** content is both stored in the content JSON _and_ injected into the HTML when saving because I couldn't figure out a reliable way to always grab the correct HTML from the head. When using the external core, you'll have to make sure to manually inject the Custom Head content into the HTML. Within the Feather Wiki code, this is done using `FW.inject.esc(p.head, true)` directly before `</head>` in the HTML, where `p` is the un-minified content normally stored in `<script id=p type=application/json>` on the HTML output (found in `FW.state.p` when loaded). Do you think that's okay/manageable? Also, the JS would almost certainly be called "Feather Wiki Skeleton" and the CSS would be something like "Feather Wiki Plumage" 😄

I think that's okay, or perhaps I'm not following what the problem might be.

I imagine that only the static code that doesn't change between Feather Wiki versions would go in the 'external' js file. Everything else, including content json and html would remain in the main file.

So that implies there needs to be a clear delineation between the always static & potentially non-static content.

I think that's okay, or perhaps I'm not following what the problem might be. I imagine that only the static code that doesn't change between Feather Wiki versions would go in the 'external' js file. Everything else, including content json and html would remain in the main file. So that implies there needs to be a clear delineation between the always static & potentially non-static content.
Sign in to join this conversation.
There is no content yet.