testing moving the functionality into small modules #5

2022-08-11T12:45:31Z

xananax commented

2022-08-11 12:45:31 +00:00

Idea:

move all the functionality currently in the /modules directory into npm modules, which can then be loaded statically through

<script type="module">
import blog from "https://esm.sh/@tickle/blogTemplate";
blog()
</script>

A single component can also be loaded:

<script type="module">
import fetchMarkdown from "https://esm.sh/@tickle/fetchMarkdown";
fetchMarkdown("thing.md").then(...
</script>

The benefits:

drastically reduced boilerplate for the end user; ready-made templates to drag and drop
bits of functionality can be loaded on demand for advanced or special templates
for us: easier to maintain, test, and write

The malefits:

code is not self contained. We could provide an automated bundle that gives the code though
the code is not local, which means functions need to favor options rather than changing them. I intend to work around that by making functions so small and specific that it's easier to write your own.

Idea: move all the functionality currently in the `/modules` directory into npm modules, which can then be loaded statically through ```html <script type="module"> import blog from "https://esm.sh/@tickle/blogTemplate"; blog() </script> ``` A single component can also be loaded: ```html <script type="module"> import fetchMarkdown from "https://esm.sh/@tickle/fetchMarkdown"; fetchMarkdown("thing.md").then(... </script> ``` The benefits: 1. drastically reduced boilerplate for the end user; ready-made templates to drag and drop 2. bits of functionality can be loaded on demand for advanced or special templates 3. for us: easier to maintain, test, and write The malefits: 1. code is not self contained. We could provide an automated bundle that gives the code though 2. the code is not local, which means functions need to favor options rather than changing them. I intend to work around that by making functions so small and specific that it's easier to write your own.

👍 1

xananax added 1 commit 2022-08-11 12:45:33 +00:00

testing moving the functionality into small modules b2a4f8d4e0

yagich commented

2022-08-11 19:35:53 +00:00

reposted from discord to continue discussion from there:

all in all, im down for separating it into modules, i think the benefits outweigh the malefits
i do have a few concerns we could iron out:

what about offline use? provide bundled libraries?
how would this affect the app? should there be a specific configuration for the app, or should there be a way to "build your own tickle" in the app?

it would also be nice to finalize the license before we put the modules out into esm

reposted from discord to continue discussion from there: all in all, im down for separating it into modules, i think the benefits outweigh the malefits i do have a few concerns we could iron out: 1) what about offline use? provide bundled libraries? 2) how would this affect the app? should there be a specific configuration for the app, or should there be a way to "build your own tickle" in the app? it would also be nice to finalize the license before we put the modules out into esm

xananax commented

2022-08-11 20:16:43 +00:00

Offline Usage

I didn't really consider offline use. Once the main site is set up, people really only need to write markdown files, local preview is not strictly mandatory after all.

But we could:

provide a cached version in the official app (capture specific strings and serve local versions which will have been cached)
provide a bundle (but that's a bit advanced for the target user, since the string needs to be changed in the HTML)

Build Your Own Tickle

This sounds like it has the potential to end up so complex it will be like using a programming language all over again.

Maybe we can still keep it manageable if we make sure to keep it simple.

Imagine:

have a limited set of supported templates. Blog, Card, Documentation, maybe a few others
have a few fields to change colors and so on (assuming the CSS is abstracted also)

These would be hard-coded in the Tickle App, to keep things simple-ish.

Later on, we could think of a spec config file instead, so people can add their own. It may be worth having a spec file (or at least Godot resource) from the start to avoid too much refactoring.

How it would work (Dream Implementation)

The way this could function:

Tickle App has several built-in configurations, but can also load a config from a gist, a text file online, etc.

When a configuration is picked, it specifies:

the CSS file
the CSS variables
the HTML string (we need specific elements in the HTML)
the HTML variables (title, loading string, etc)
if files.txt is used or not

Then, it acts as if index.html was requested, downloads all the online relevant files and caches them temporarily, so it can use them when there's no network.

But all of this is in my eyes in a far future.

### Offline Usage I didn't really consider offline use. Once the main site is set up, people really only need to write markdown files, local preview is not strictly mandatory after all. But we could: 1. provide a cached version in the official app (capture specific strings and serve local versions which will have been cached) 2. provide a bundle (but that's a bit advanced for the target user, since the string needs to be changed in the HTML) ### Build Your Own Tickle This sounds like it has the potential to end up so complex it will be like using a programming language all over again. Maybe we can still keep it manageable if we make sure to keep it simple. Imagine: - have a limited set of supported templates. Blog, Card, Documentation, maybe a few others - have a few fields to change colors and so on (assuming the CSS is abstracted also) These would be hard-coded in the Tickle App, to keep things simple-ish. Later on, we could think of a spec config file instead, so people can add their own. It may be worth having a spec file (or at least Godot resource) from the start to avoid too much refactoring. ### How it would work (Dream Implementation) The way this could function: Tickle App has several built-in configurations, but can also load a config from a gist, a text file online, etc. When a configuration is picked, it specifies: - the CSS file - the CSS variables - the HTML string (we need specific elements in the HTML) - the HTML variables (title, loading string, etc) - if `files.txt` is used or not Then, it acts as if index.html was requested, downloads all the online relevant files and caches them temporarily, so it can use them when there's no network. But all of this is in my eyes in a far future.

xananax added 1 commit 2022-08-11 20:32:01 +00:00

made all files conform; simplified template loading 8e7ce406ff

xananax added 1 commit 2023-05-09 02:03:50 +00:00

refactor 7d3f5b67cf

xananax added 1 commit 2023-05-13 15:26:52 +00:00

tickle functionality restored 9b3b3e15b6

xananax added 1 commit 2023-05-13 15:58:40 +00:00

minor refactoring 55b59bfd2c

xananax added 1 commit 2023-05-18 21:33:38 +00:00

added a few loading utilities 3d348710e0

xananax added 1 commit 2023-06-06 22:45:20 +00:00

temp mid-work backup commit eadca78080

xananax added 1 commit 2023-06-07 16:51:22 +00:00

smol update cde1e58a47

xananax added 1 commit 2023-06-07 20:07:51 +00:00

smol updates even mor b01f6444d0

xananax added 1 commit 2023-06-13 16:50:18 +00:00

general updates 93efef50a5

You are not authorized to merge this pull request.

This pull request can be merged automatically.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin split-into-modules:split-into-modules

git checkout split-into-modules

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xananax/tickle#5