upvent / upvent-svelte Goto Github PK

Marketplace should work different and not be a full featured e-commerce "solution" but a bridge to make payments with different services.

The default bootstrap distribution comes with a special Google Font, however, as far as I know, this font is retreived via CDN. We do not like CDN's so, we should find a way to include one or two Google fonts without using a CDN.

The external meta-tags package seems to be broken when making references to other sites / titles in our current code. This also conflicts with the main index.html file provided by the Svelte template. Try to fix the current meta tags library or make a custom component.

.webp files are faster to load, provide better compression and help a lot when it comes to websites. To increase our pagespeed score all of our .png images need to be replaced for .webp versions of themselves.

Robots.txt cannot be found by SEO engines. A Svelte implementation of such file shall be done.

According to Rocket's rationale on being async:

[...] Allows route handlers to perform wait-heavy I/O such as filesystem and network access while still allowing other requests to make progress.

So the server backend should be as async as possible without breaking things. Routes are specially prone to this if we don't handle awaits properly.

Glassmorphism looks cool on many sites. Maybe UpVent should begin using some of it's awesome style instead of keeping the old material design one. Maybe fluent-design inspiration too (?)

After no-reason at all. Fetching REST API posts has stopped working. Due to the highly-useless CORS policy. A workaround for this needs to be found.

Ideally all imports should be the whole route to the actual imported ES module. This optimizes compile time (even if we have a tree shaker) and increases readability.

Blog posts should be written in markdown or org format to ensure easy writing and reading.

Question is...should we save the raw markdown in our database? 🤔 or should we make a folder and make the database tell where the file is and make Svelte process it.

Thank god this isn't in production yet. API authentication is needed to create, update and delete objects within our current project.
This should implement the basic user/admin schema, however a single admin per instance should suffice.

More investigation on Rocket's auth capabilities is needed.

This site isn't warning-free. Svelte is showing some warnings, most of them accessibility warnings. Some of them can be solved easily by just looking at the console messages.

Sveltestrap allows us to import bootstrap-icons from our node packages. However this begins to be an issue since importing them in main.js results in Svelte not finding the .woff / .woff2 fonts resulting in broken bootstrap icons.

Console error:

[02:18:58] 404 ─ 0.29ms ─ /build/fonts/bootstrap-icons.woff2?30af91bf14e37666a085fb8a161ff36d
[02:18:58] 404 ─ 0.28ms ─ /build/fonts/bootstrap-icons.woff?30af91bf14e37666a085fb8a161ff36d

A deployment without tests it absolute garbage. Therefore this crate / server should include a good test suite to ensure the REST api / Frontend are working as expected.

I still haven't decided on how to authenticate / how does authentication works on API's.

When known, I'll decide if I'll make an authentication route with a form or a separate admin panel to manage the application.

Some components are being left unused and Sveltestrap hasn't been updated and some dependencies are getting a little insecure by now. We can either ditch Sveltestrap completely at the expense of having to rewrite the modals we use here or hope that the library gets it's sec issues fixed soon.

Traits in theory could help us reduce the current models.rs file by creating common methods for various models.

All models have the following methods:

• show
• all
• update_by_id
• insert
• delete_by_id
• all_by_x (where x is either name or title)

After finishing all common methods a way to implement default traits for all models could help us reduce our codebase and make compile times faster.

As Richard Clayton states:

The point of a UUID is to have a universally unique identifier. There's generally two reason to use UUIDs:

1. You do not want a database (or some other authority) to centrally control the identity of records.

2. There's a chance that multiple components may independently generate a non-unique identifier.

This will help us remove the classic id = 1, id = 2, id = 3 identifiers from our database and instead identify objects by their UUID. This makes queries easier as a UUID is fixed and won't change or be re-ordered in comparison to normal ID fields in a database.

Add an image route field to the database in the models section. This should help us deal with placeholders or place our images wherever we like.

This site has a heck lot of JS in and on itself, and without the main SvelteJS file this would just render a plain HTML tag with no response whatsoever. Due to this, users with JS disabled should be warned that our site doesn't work without JS enabled.

This would be more useful than the universal modal.

A way to make svelte serve multiple .html files or routes is needed to let users view different URL's

This must be achieved without SvelteKit. A routing library could be helpful or doing the routing manually. Further research is needed. If everything else fails we'll just have to load / unload all components manually.

When rendering the Svelte components, a small margin (around 5px) is rendered in compnents that need the entire screen. This might be due to viewport issues or an issue with Sveltestrap.

How to reproduce

Add the shadow class to the Navbar.svelte component.

Screenshot

Being an early alpha project Sqlite is our DB pick (for now), while migrating to another database should not take long, it can be frustrating to new users.

Investigation is needed to see if it is possible to let users choose their database on build actions. The main problem here are the up.sql and down.sql files which have DBMS-specific syntax.

Diesel only supports Postgres, MariaDB and Sqlite.

If no progress is made, a wiki article on how to swap servers should be written.

This is reserved for the BETA release.

We have cargo in our weaponlist to document our backend codebase, however further elaboration is needed for people who wishes to deploy their own fork using Rust + Svelte. The GitHub wiki will help us with this.

In various components we have an API_URL variable. If users want to consult their own API they need to be able to change this API_URL to their liking. However this has come to be difficult as there is not much documentation on how to load a config.js file on Svelte.

404, 500 and 403 error handlers in rocket should be implemented to give users feedback on what went wrong.

Reduce the page's size by adding the hardcoded array of FServices under FServices.svelte

sitemap.xml also doesn't exist (#32). A svelte implementation needs to be done as well.

The label says it all, Svelte can't do everything for us.

Svelte sometimes doesn't know hot to handle routes properly with tinro. As such, 404 pages are not being displayed properly or just as an empty pages.

Importing bootstrap icons from npm is kind of a pain. I don't know whose bad desing is the one to take the blame here (svelte's or bootstrap-icons package).

A way to import the font and icons properly shall be found. In case we are unable to include those a manual font import shall be done.

Diesel seems to be the more sensible solution for this. Further investigation is needed as diesel doesn't seem to work properly with SQLITE databases. So this should be done in another database engine like MySQL (MariaDB) or PostgreSQL.

This is the nth attempt made in this organization to provide users with a functioning dark mode. However, things get difficult when doing so, as dark mode tends to be messy when a button is made. Still an effort shall be done / considered in order to provide a better experience to our users.

Django made this interesting when we worked on the first webpage version. Rocket will make this even more interesting with form handling. In case we cannot find a way to handle rocket forms properly we should search a contact form provider that respects our users privacy.

Even if #14 is resolved, docstrings should be applied to all model methods, that way users know exactly what are we talking about when reading the documentation.

The blog system uses the WP-API to extract blog posts and many things more. However, blog routing isn't being handled properly and thus, no sharing URL for specific blog posts exists.

If anyone knows how to fix this without using Sveltekit contribs are welcome.

Navbar looks way too big in mobile but, some elements look really tiny on a large computer screen. Some editing needs to be done in order to make it look good.

Testing the database is an important part of a REST API. A way of populating the database with dummy data is recommended for testing functions. This can be done with the test suite or just a simple shell / rust program.

It would be better to hardcode the image routes in the HTML of each component and see if this improves the webpage's memory usage.

With the new routing library addition. A new file structure + components should be implemented.

This route sometimes fails due to a 404 error and sometimes not. Anyways routes.rs should be checked.

This could be a REST client issue as well. Chrome rest clients cannot seem to process GET and Firefox ones don't process POST.

Testing with a real tool like curl is needed.

The bloated web is not cool. So we don't want to contribute to that. As a small goal for UpVent development , the entire website should not weight over 2MB (2048 KB).

As of now (actual commit) the total build size is: 2.8 MiB (2 971 808 bytes).

It would be nice to animate elements with fade / slide animations present in VisualFX. For some strange reason svelte is not recognizing the transition:fade="{{ duration: 2000 }}" command. I'll have to check that later.

Sometimes an image / link constant is defined multiple times, this may or may not (I don't know how does Svelte optimize the final JS code) result in slower / more memory consuming code in production.

I don't know much about svelte but shared data between components should be used to improve memory allocation.

This is the faulty code:

    @supports (backdrop-filter: none) {
	    .navbar-upvent {
            backdrop-filter: saturate(100%) blur(100px);
            -webkit-backdrop-filter: saturate(100%) blur(100px);
	    }
    }
    @supports not (backdrop-filter: none) {
        .background {
            background-color: #FAFAFA;
        }
    }

Using svelteJS would help us with a better JSON api to fetch and get the most recent blog entries or the latest blog entry and show it in the main page for more blog reading users.

Currently the only use for Svelte Meta Tags is a JSON-LD schema for the UpVent organization. This plugin needs to be squeezed for more juice and allow us to render SEO tags dynamically using the power of tinro.

To prevent spam. An hcaptcha widget needs to be present in the contact form.