DEV Community: Jace

CSS, The Old

Jace — Sun, 16 Apr 2023 14:15:51 +0000

CSS is more than simply picking a background color

Let's take a look at how things were before and how not to do those things today.


Float Layouts
Padding Aspect Ratio
Pixel Values
Break Out of the Parent

Float Layouts

🔝

You're probably familiar with this:

.el {
    float: left; /*left, right*/
}
.after {
    clear: left; /*left, right, both*/
}

In the old days this could be used to align two containers next to each other. It was more a hack than an actual way to do it, due to the effects it had on the parent... Except it was the way to do it.
The element got pulled out of the flow (in a way), which meant that the parent would collapse to 0 if there were no other children to give it a height, or it didn't have a height of its own.
The clear-method was a way to tell the parent not to do that; by giving the element after the floated element the clear property.

This way of layout whas rather fragile and with the new layout methods like flex and grid; float quickly became obsolete and outdated.

☝ Refactor old code to use flex or grid instead of float

But float still has its usecases. When you want text to follow the curve of an image, float is the perfect way to do it.

<div class="parent">
    <img src="your_img.png" />
    <p>lorem500</p>
    <p>lorem200</p>
    <p>lorem100</p>
</div>

First of all, you would want the image to be the first element. If it's the last one, it won't work. And give it the float property.

img {
    float: left;
    /*
    I curve the image by using border radius; 
    using the shape-outside property works as well
    */
    border-radius: 100%;
    widht: 150px;
    height: 150px;
}

But now we still have the collapsing problem, which is not really noticeable as long as the text is long enough. But why take chances?
To fix this, we could use the clear-method again; but I prefer using the parent. It's a cleaner way to do this.

.parent {
    display: flow-root;
}

A display: flow-root changes the parent's context, in this case, it means that it will grow to fit the content, even if the content is floated.

☝ Use float with display: flow-root to curve text around an image

Padding Aspect Ratio

🔝

A short one; before we had the aspect-ratio property, they would use a different method to achieve this effect:

.element {
    /* 1:1 AR */
    width: 50px;
    height: 50px;
}

Great! But not responsive, because this would not work:

.element {
    width: 100%;
    height: 100%;
}

Even though both values are 100%, they are not the same size. Because percentages for sizes refer to the sizes of the parent element.

So they found this hack:

.element {
    padding-top: 100%; 
    /* 1:1 AR: 100% */
    /* 16:9 AR: 56.25% */
    /* 4: AR: 75% */
    /* 3:2 AR: 66.66% */
}

But this did not work if their element had child elements like text. The "aspect ratio" would be added to the height of the elements.
So they did following:

.parent {
    position: relative;
    padding-top: 100%; 
}
.child {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
}

But this still is not responsive to the content. The content of the child could still overflow.

Luckily those days are over.

☝ Use the aspect-ratio property to keep a constant ratio between with and height that is responsive

Pixels Values

🔝

A pixel. A small, square speck of which your screen is build out of. But in CSS-land, a pixel is a unit measurement, one of the first, if not the first.

If you want a square of 50 by 50 pixels, you would use the following:

.square {
    width: 50px;
    height: 50px;
}

Nothing ground-breaking. But nowadays we have a lot more units that we can use like rem, em, ch, vh, vw, dvh, dvw...
Each unit has their own use case, their own reference point; and their own perks that should be taken account for.
For this section, I will only take al look at the first three of that list.

Rem
: A unit that has the roots font-size as reference point; by default 16px.
(You can change this value by changing the roots font-size; but you should NOT do this.)

Em
: A unit that has the elements font-size as reference point. So if you change the font-size, the em-value changes as well.

Ch
: A unit that has the elements 0 character's width of the current font and font-size. So if you change the font-size, the ch-value changes as well.

When should you use each? And when not?

Rem

If you would use pixels, use rem instead. That is a good start in my opinion. So, font-size, width, height...
The rem unit is more accessible than the pixel unit. Because a browser can easily increase the rem default value when a user wishes to use larger fonts for example. If you use pixels instead, the fonts on site might not be enlarged, which is bad UX.
Yes, it might create some weird values for some regular used pixel-values due to the base 16 our rem unit uses, but I find myself using CSS custom properties in most cases anyway, so it doesn't matter much.

Em

If you want a unit that sizes with your font-size for a certain component, use em. Let's say we have a button with font-size: 0.875rem and we want a padding on all sizes of 0.4375rem.
Now later you might want the same button but larger, let's say font-size: 1.25rem; but you want to keep the same ratios, you want to "scale" the button up. In that case, you might want to change the padding value to 0.5em instead. So now the only value you need to update is the font-size.

/* old */
.btn {
    font-size: 0.875rem; /*14px*/
    padding: 0.4375rem; /*7px*/
}
.btn[large] {
    font-size: 1.25rem; /*20px*/
    padding: 0.6125rem; /*10px*/
}
/* new */
.btn {
    font-size: 0.875rem;
    padding: 0.5em;
}
.btn[large] {
    font-size: 1.25rem;
}

It makes the code a lot cleaner; as you can see, using a value like 0.4375rem is a bit cluttering, for sure if you don't know what that value translates to in pixels, it might seem a random value.
But by using the 0.5em, now we simply know: half of the font-size.
And it beautifully scales the button up.
Many use this trick to scale box-shadows as well.

Ch

The ch unit makes it very easy to constrict a paragraph to a certain number of characters, heck, I would not be surprised if that was the exact reason it was introduced.
It works best with monospace fonts in that way, due to all characters being the same width. It does work for other fonts too, but the result is less satisfying in my opinion.

Similar to the em unit, ch is linked to the font-size. They are not the same though, I have noticed that for some fonts 1em and 2ch are similar in size, but not exactly so. This is due to the em unit being linked to the fonts height, where ch is character width, I believe. The wording in their descriptions are a bit fuzzy to say for sure.

According to some UX articles, a length of 45 to 90 characters is the best length for paragraphs to ensure legibility, and yeah, that seems to work.
Personally I shoot for max-widths of 70 to 75ch, which fits neatly in that range.
This unit makes it really easy to implement that theory in our web designs.

Articles I quickly scanned through for that character-range:
Practical Typography: Line Length
Webflow: Ch unit

Break out of the Parent

🔝

You might find yourself in this situation:

<main class="max-width">
    <article>
        <p>lorem500</p>
        <p>lorem200</p>
    </article>
    <div class="full-width">
        <article>
            <p>lorem500</p>
                <p>lorem200</p>
        </article>
    </div>
    <article>
        <p>lorem500</p>
        <p>lorem200</p>
    </article>
</main>

Where the max-width constrains the width of its children to, let's pick, 75rem; and the full-width wants to span the whole site width of, let's say, 100vw.

.max-width {
   max-width: 75rem;
   /*to center the container horizontally*/
   margin-inline: auto; 
}
.full-width {
   width: 100vw;
}

Well, this is not going to work; unless a messy overflow was your goal. So I often see following to fix this:

(for those thinking: width: 100%; that would mean the same width as the parent, which is not the desired effect as it would not break out)

body {
   overflow: hidden;
}
.max-width {
   max-width: 75rem;
   margin-inline: auto;
   overflow: visible;
}
.full-width {
   position: relative;
   left: -50vw; /*pull out*/
   transform: translateX(-50%); /* push back in*/
   width: 100vw;
}

You would fix the overflow issue by removing scrollbars on the main width overflow: visible and counteract the overflow-issues on the body with overflow: hidden.
(Yes, you're better of specifying overflow-x: hidden in production)
Then you would position the article in the center by pulling it back by half the viewport width and pushing it back by half its own length.

And this would work, were it not for scrollbars.
The scrollbar would push the content further back by, idk, 20 pixels on Chrome, 30px on Safari and 0px on browsers with floating scrollbars.
(No, I did not measure the scrollbar thickness of those browsers, fyi, these values are random)

There is no way of counteracting these offsets, due to there being no standards about scrollbars and their width. Not even with JavaScript, or at least not reliably.
This means that for a best case: the content does not line up with the rest; or a worst case: overflow issues that completely muck up your design.

So, how do you break out?
In my opinion, you don't. I would put the max-width class only on the blocks that actually need it.
But in the case you can't add classes to those elements except the full-width class, you could do something like this:

.max-width > :not(.full-width) {
   max-width: 75rem;
   margin-inline: auto;
}

There is a catch though, and that is when the children of .max-width are not containers themselves.

<main class="max-width">
    <!-- these children -->
    <h1>lorem5</h1>
    <p>lorem500</p>
    <!--  -->
    <article>
        <p>lorem500</p>
        <p>lorem200</p>
    </article>
    <div class="full-width">
        <article>
            <p>lorem500</p>
                <p>lorem200</p>
        </article>
    </div>
    <article>
        <p>lorem500</p>
        <p>lorem200</p>
    </article>
</main>

Let's say that I want all p tags to be a maximum of 60 characters long; the max-width can be overwritten to be 60ch, that is not the issue; but the text will not be able to align left with the rest of the content, due to the margin-inline: auto. And removing the margin-inline of those elements would mean that the p would stick to the edge of the screen instead. You could try to hard-code the margin-left so it lines up again, but I don't recommend doing that.

You will have to ensure the HTML is properly wrapped; by a div, or a proper semantically correct element.

<main class="max-width">
    <div>
        <h1>lorem5</h1>
        <p>lorem500</p>
    </div>
    <article>
        <p>lorem500</p>
        <p>lorem200</p>
    </article>
    <div class="full-width">
        <article>
            <p>lorem500</p>
                <p>lorem200</p>
        </article>
    </div>
    <article>
        <p>lorem500</p>
        <p>lorem200</p>
    </article>
</main>

Something to think about which method you prefer. Use verbose classes on the elements that need it, or only add a class to divergent items.

☝ Don't use width:100vw to break out of a container parent; rethink how to structure your HTML / how to use your CSS-classes
if you can, and curse if you can't.

In case you only need a background that spans the whole site-width, I recommend this short by Kevin Powell: Bleeding Background as they do a way better job explaining how to than I ever could. 😉

See you in the next one! 👋

Remote with FTP

Jace — Mon, 03 Apr 2023 12:36:51 +0000

I like using FTP for file management on a site. I prefer it over using the file manager GUI of my hosting service. Unless I work with ZIP files, because unzipping a file on the server is faster, for me at least. But back to FTP.

My current workflow is building a site locally and upload it to the server (via FTP) when it’s done. Check if any functionality is broken due to the environment differences and fix those. So at the moment I don’t need to upload that often.

But recently I entered a project where I could not really do that without downloading thousands of files, which takes days. So I would have to style a page almost blindly, upload it and see what the result would be. Edit and upload again. That would be many uploads every minute that I would have to do manually. And I am not about doing stuff manually.

So I asked a colleague what their solution was, and a ftp plugin for your IDE was their answer.
I went looking for a VS-Code extension and found (this one).
It’s pretty good. Its documentation goes over a lot more than what I use and need at the moment. So I’m summarizing the options here in case I (inevitably) forget how it works. 😅

Setup

Note that I am using the VS Code plugin, there will likely be differences if you use a different instance of this plugin for your own IDE.

For starters, you need to install the plugin (you can use the link above, or search for SFTP in the Extensions-tab in VS Code), and have a project folder ready.

- root

Go to your command pallet (ctrl+shift+p on Windows) and type in SFTP: Config.
This will create and open a sftp.json file in a new folder in our root.

- root
    - .vscode
        - sftp.json

The file would look a bit like this:
root/.vscode/sftp.json

{
    "name": "My Server",
    "host": "localhost",
    "protocol": "sftp",
    "port": 22,
    "username": "username",
    "remotePath": "/",
    "uploadOnSave": false,
    "useTempFile": false,
    "openSsh": false
}

You change the host, username and port to your own login data, provided by your host.
You can add the password field if you want, otherwise you’d be prompted to fill in your password on connection.

The remotePath denotes the folder you wish to target, currently it’s set to the root. You could change it to only download a selected folder. Might be a smart idea if you have a site build with a file-happy CMS like Joomla or Wordpress.
Reopen your command pallet and now you could try connecting using the download command down below.
If nothing gets downloaded and you are sure your login data is correct, try changing the "protocol": "sftp" in the config file to "protocol:" "ftp".

Download

The following command fetches all the files in the targeted folder. SFTP: Download Project. They will be downloaded to the root folder. Use this to initiate your folder.
If no files present, nothing will be downloaded, so perhaps make connection using your ftp-application to add a test-file if none are present.
You could also use SFTP: Sync Remote->Local to do the same.

Upload

The command SFTP: Sync Local->Remote will push any files in your root to the designated folder. It is smart enough to only sync the files that changed since the last upload.

Boundaries

You might have noticed that the .vscode folder also got uploaded, with our file with credentials. We don’t want that, so let’s ignore this folder when uploading. (Don’t forget to delete that file from your FTP.)
root/.vscode/sftpconfig.json

"ignore": [".vscode"],

You could add any other folders you want to ignore, but in some cases that gets messy. For example, I like using node SASS and this means a lot of folders I don’t want to upload: the node-modules and any folders with SASS-files.
In that case we can constrict any fetch and push action to a single folder.
The rendered files get saved in a public folder, or live folder. Or whatever name you or your framework set it up to be.

By using the context option, we can border of a folder.
root/.vscode/sftpconfig.json

"context": "live"

So only the contents of that folder get synced.

- root
    - live
    - .vscode
        - sftp.json

One thing I noticed, is that renaming files or folders does not play too well with this plugin. Instead of renaming, it creates a new file. So you would have to delete the old files. In that case I would simply delete the target folder with my ftp app, then sync my local environment to the server. This would ensure that no old remnants remain. It's a bit meh 🙄, but whatever. Overall it's still a better experience.

In conclusion

Copy the next snippet and replace the <login credentials> for a quick setup.

{
    "name": "My Project Server",
    "host": "<localhost>",
    "protocol": "<ftp>",
    "port": <21>,
    "username": "<username>",
    "password": "<password>",
    "remotePath": "/",
    "context": "live",
    "uploadOnSave": false,
    "useTempFile": false,
    "openSsh": false
}

The Electron Saga 3️⃣: All beginings have an end.

Jace — Thu, 23 Mar 2023 19:04:40 +0000

And we are back for our latest part of the Electron Sage. As this series is more about the setup I will only go so far, as building the app itself is not really linked to the workings of, and working with Electron.

Frameworks?

When I first started with Electron, I did not think about using a JavaScript framework; most of the time I use PHP for my web development, so it did not come to mind that such a framework could be useful.

The app I wanted to build would be able to do a bit more than just add items to a list I could edit. It needed to be expandable; so I build my first page with a nice sidebar and a main... and came to the realisation that I would need to copy the sidebar each time I would add a new page.
When using PHP, you would build a page index.php, which would contain the sidebar and an empty main that would be populated with a require- or an include function. What file you would include would depend on the current location (the URI).

<html lang="en">

<head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">

   <title>My Site</title>
</head>

<body>
    <header>
        <h1>Hello World</h1>
    </header>

    <aside>
        <nav>
            <ul>
                <li>navitem</li>
                <li>navitem</li>
                <li>navitem</li>
                <li>navitem</li>
            </ul>
        </nav>
    </aside>

    <main>
        <?include 'path_of_file'?>
    </main>
</body>

</html>

But no PHP, so no HTML-include.
I shrugged and instead of looking for a NPM package that could help me, or to look into a framework like Svelte; I decided to try importing with vanilla JavaScript. It worked, kind of.

Layout

First of; creating a new folder classes in /front/logic and a new file app.js.
Then linking the app.js file as a module.

/front/index.html

<head>
    <meta charset="UTF-8">
    <meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline';" />

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>My App</title>
    <link rel="stylesheet" href="styles/reset.css">
    <link rel="stylesheet" href="styles/main.css">

    <!-- right here  -->
    <script type="module" src="logic/app.js"></script>
</head>

Great, check if the connection is working by logging the values from last time:

/front/logic/app.js

console.log(E_system.mode);
console.log(E_system.platform);

No breakage? Great, let's see, how do we want it to work?
Well, when I click a button in the nav; the content should be switched out.
I would like to be able to include content in a header, main and footer separately as to not break my main layout; so let's build up a nav and include some slots in our body

/front/index.html

<body>
    <nav id="feature-nav" class="c-wrapper">
        <ul>
            <li>
                <button sheet="home">
                    <span>Home</span>
                </button>
            </li>
            <li>
                <button sheet="todo">
                    <span>Todo</span>
                </button>
            </li>
            <li>
                <button sheet="tracker">
                    <span>Schema</span>
                </button>
            </li>
        </ul>
    </nav>
    <div id="app-interface">
        <header>
            <content-slot></content-slot>
        </header>
        <main>
            <content-slot></content-slot>
        </main>
        <footer>
            <content-slot></content-slot>
        </footer>
    </div>
</body>

You can see I added an attribute I called sheet to all buttons. I also created a folder /front/sheets and added some HTML-files with names that correspond with those attribute values.

It is certainly possible to add aria-labels like aria-current and aria-controls to the buttons; or add a skip-to-content button above the ul, but those features are a bit out of scope for this checking-out series.

I want the sheet-files to be plain old HTML-file; I want three containers that I can target with the JS dom-api and just write content as I would normally.

/front/sheets/home.html

<header-content>
    <h1>Home</h1>
</header-content>

<main-content>
    my content
</main-content>

<footer-content>
    my footer
</footer-content>

JS

The class is called page_loader, and it just gets imported and called. The is_ready method checks to see if our index.html has all the required elements to work; and the activate() method enables the button click.

import { D$ } from "./fn/dev.js";
import { page_loader } from "./classes/loader.js";

console.log(E_system.mode);
console.log(E_system.platform);

//? Load Pager
{
    const page = new page_loader();
    if (page.is_ready()) {
        D$(console.log, "Page Loader Ready");
        page.activate();
    } else D$(console.warn, "Page Loader not Ready");
}

It works by using the fetch-api and a DOMParser object.
When a button is clicked, the class checks which sheet it links to and fetches the file with, well, Fetch.
A plain text-string is returned; which is passed on to a DOMParser. This JS-object is able to transform our plain string back to HTML.
Then we use the good old DOM-api to query our content-blocks
(<header-content> <main-content> <footer-content>)
At last it's just a matter of removing the old content from our index.html and pasting in the new content to have our final result.

Helper functions;

I had made some helper functions and saved them in the files /front/logic/fn/dev.js and /front/logic/fn/dom.js.

$D()
: Is a function that fires the passed through function only when the app is in development. It uses the is_dev variable we bridged over before.

$S()
: An abbreviation for querySelector

$SA()
: An abbreviation for querySelectorAll

page_loader class

First; some more helper functions; these do most of the work; they fetch and convert data.
And we import the previously mentioned helpers as well.

/front/logic/classes/loader.js

import { D$ } from "../fn/dev.js";
import { S$, SA$ } from "../fn/dom.js";

/**
 * @description get the sheet-attribute off of buttons
 * @param {HTMLButtonElement} _btn
 * @returns {string} - Sheet
 */
const get_sheet = (_btn) => {
    return _btn.getAttribute("sheet") || "";
};

/**
 * @description fetch sheet and return its data
 * @param {string} _sheet
 * @returns {response} - string
 */
async function find_sheet(_sheet) {
    const path = `./sheets/${_sheet}.html`;
    const F = await fetch(path, {
        method: "GET",
    })
        .then((response) => {
            // D$(console.log, response);
            return response.text();
        })
        .then((data) => {
            return data;
        })
        .catch((error) => {
            D$(console.log, error);
            return "";
        });
    return F;
}

/**
 * @description convert string to html of header-main-footer
 * @param {*} _html
 * @returns {array} - object of header_data, main_data, footer_data
 */
const data_to_html = (_html) => {
    var parser = new DOMParser();
    var doc = parser.parseFromString(_html, "text/html");
    const header_data = S$("header-content", doc)?.innerHTML.trim() || "";
    const main_data = S$("main-content", doc)?.innerHTML.trim() || "";
    const footer_data = S$("footer-content", doc)?.innerHTML.trim() || "";
    return [header_data, main_data, footer_data];
};

And the main class; it does little more than querying all nav-buttons with the sheets attribute and the <content-slot> tags and attaches a click-event to those nav-buttons.
There are more functions you could add to the class; for example, automatically load the home.html sheet on startup. Or the sheet last used.
And some navigation functionality like showing what the current sheet is.

export class page_loader {
    #header_slot;
    #main_slot;
    #footer_slot;

    #all_nav_btns;

    constructor() {
        this.#get_targets();
        this.#get_nav();
    }

    // query native elements
    #get_targets() {
        this.#header_slot = S$("#app-header content-slot");
        this.#main_slot = S$("#app-content content-slot");
        this.#footer_slot = S$("#app-footer content-slot");
    }
    #get_nav() {
        this.#all_nav_btns = SA$("#feature-nav [sheet]");
    }

    /**
     * Fetch given sheet and render the data in the app
     * @param {string} _sheet - sheet of data to fetch
     * @param {HTMLButtonElement} _btn - button to turn on in the nav
     * @returns {void}
     */
    async #render(_sheet, _btn) {
        const data = await find_sheet(_sheet);
        if (!data) return;
        const [header_data, main_data, footer_data] = data_to_html(data);

        this.#header_slot.innerHTML = header_data;
        this.#main_slot.innerHTML = main_data;
        this.#footer_slot.innerHTML = footer_data;
    }

    /**
     * @description checks to see if the loader has succesfully retrieved all nav btns and the content slots
     * @returns {boolean}
     */
    is_ready() {
        if (
            this.#all_nav_btns &&
            this.#header_slot &&
            this.#main_slot &&
            this.#footer_slot
        )
            return true;
        return false;
    }

    /**
     * @description function to activate click events on nav-btns
     */
    activate() {
        this.#all_nav_btns.forEach((btn) => {
            btn.addEventListener("click", (e) => {
                const sheet = get_sheet(btn);
                this.#render(sheet, btn);
            });
        });
    }
}

It works but...

What I noticed when using this class is, that when I write JavaScript in a <script> tags in a sheet.html; it does not get triggered in the index.html; which does not mean it is safe to allow any scripts to infiltrate those files though. My guess is that the script gets run when the fetch-request reads through the file and not when the content gets 'pasted' into our index.html.

But what if you want to import some JS anyway? Well; I noticed that custom-elements get rendered properly, (if they are defined in our app.js file); so you could use a custom-element to autoload JS code.

Notice: I can't really speak about the security of this method; I would say not too bad, but if those HTML files got corrupted anyhow, the class would have no way of knowing, never mind handeling.

Conclusion: use a framework 😉

Series Conclusion

In these 4 articles, I set to lay out my first steps into starting with Electron and desktop-app making. I must say I was surprised how little extra setup it is compared to web development, for this example at least. I assume that if I where to dive deeper into this world, it would require some more setup.
I found that it is certainly possible to work with Electron without a framework (I fully build my app before realizing I could have used one); but it would have improved my dev-experience a bit.
I like how close it is to web-development I'm used to, and working with it feels quite nice, but I can't really compare how it holds up against other app-dev frameworks.
However, the unsolvable errors at the start of my journey should be mentioned (The Electron Saga 0). They did cause a bit of confusion and worry.

Overall, it was fun mocking around this new environment, away from the projects lurking over my shoulder.
Speaking of which, I should return to those. I hope you got something out of this series.
See ya! 👋

The Electron Saga 2️⃣: Bridge building

Jace — Fri, 30 Dec 2022 14:29:00 +0000

Hi there; a short message before we jump into the code:

With this being the third article of this journey, I thought: why not open a Github Repo for this project? So here you go.
For those who would like access to the source code. The latest version of this project can be downloaded/pulled from this repo.
Note that some of the older commit-messages may be a bit wonky. I am terrible at naming things sometimes.

Now let's jump back into the project.

Last time we build the backbone and the start of a body. Now, these two can't communicate with each other yet; and sometimes we sort of do need that.
For now we will transfer a couple of variables.

If you remember, last time we had a variable which could tell us if the app was in production or not:

const is_dev = process.env.NODE !== "production";

Well, wouldn't it be usefull to have this constant in our body as well? I would think so, so let's take a look.

Build the bridge

Remembering back; we told electron to preload a preload.js file.

/main.js

function create_window(_name) {
    const my_window = new BrowserWindow({
        title: "My Lab",
        width: 1000,
        height: 750,
        webPreferences: {
            contextIsolation: true,
            nodeIntegration: true,
            // We are telling that here!
            preload: path.join(__dirname, "preload.js"),
        },
    });

    my_window.loadFile(path.join(__dirname, `./front/${_name}.html`));

    if (!is_dev) return;
    const dev = new BrowserWindow();
    my_window.webContents.setDevToolsWebContents(dev.webContents);
    my_window.webContents.openDevTools({ mode: "detach" });
}

So if you didn't create an empty preload.js file in the root folder and ran into some trouble last time... Now you know why. 😉

This preload.js acts like a bridge between our backbone and our body.

Let's build some containers to bridge over.

/preload.js

const { contextBridge } = require("electron");

contextBridge.exposeInMainWorld("E_system", {
    platform: process.platform,
    mode: process.env.NODE,
});

The contextBridge.exposeInMainWorld function takes in two params, the first on is the object-name you wish to use. The second is the object with key-value pairs of the actual data.

In this case we save the users system (mac, linux, windows) in the E_system.platform variable; and the production mode, (live, in production) in the E_system.mode variable.

Important to note is that these variables are read-only.

Great, now we have access to backbone-data. Let's see it.

Cross the bridge

/front/index.html

<html lang="en" spellcheck="false">
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline';" />

        <meta name="viewport" content="width=device-width, initial-scale=1.0" />

        <title>My Lab</title>
    </head>

    <body>
        <h1>Hello World</h1>

        <script>
            console.log(E_system.mode);
            console.log(E_system.platform);
        </script>
    </body>
</html>

Let's fire up Electron npm start and check the console:

C:\Program Files\nodejs\node.exe

win32

Ha, 🤔
The platform variable logs something we expect, the win32 is indeed the machine I'm currently working on...
But the mode does not say anything about dev-mode or production.

Well, take a look at the is_dev variable declaration

const is_dev = process.env.NODE !== "production";

If we check is_dev variable against our E_system.mode, we would get true. C:\Program Files\nodejs\node.exe is not equal to production.

So let's change the code a bit so we get a variable we could use without getting a weird string.

/preload.js

contextBridge.exposeInMainWorld("E_system", {
    platform: process.platform,
    is_dev_mode: process.env.NODE !== "production",
});

/front/index.html

<body>
    <h1>Hello World</h1>
    <script>
        console.log(E_system.is_dev_mode);
        console.log(E_system.platform);
    </script>
</body>

Now let's refresh the Electron app. (The shortcut ctrl+r is set up in our app-menu to reload the frontend of our app).

We get the values we expected logged out.

true

win32

Great! We build a bridge and successfully crossed it.
Let's stop here for now.
Will see you in the next one! 👋

The Electron Saga 1️⃣: Setup

Jace — Sat, 10 Dec 2022 13:49:14 +0000

It's been a while, hasn't it? But let's not dwell and dive back into the project.

The goal for this chapter is to try give a bit of a clearer image of what is going on. Rather than tell you about mishaps I encountered, I'll try and show you how it works.

Folder Structure

 - root
    - front
    - node_modules
    - .gitignore
    - main.js
    - package.json
    - package-lock.json
    - preload.js

First: background noice (mostly)

.gitignore
: if you are familiar with Git you know what this one does.
It allows us to exclude files and folders from the git repo. In our case it removes the node_modules folder and the package-lock.json. You don't need it if you don't use Git.

package.json
: this file is generated when we setup everything we need, including Electron; and contains some functions to symplify workflow. We will take a look at this one a bit down below.

package-lock.json
: magic happens here. It is a file that is generated after a Node project is initialized.

Next up: Electron

main.js
: this is the core of our project. It contains the code which allows us to 'communicate' with Electron.
You could say it is the backbone of our project and it also acts like a key to the user system.

preload.js
: this file is the bridge between our backbone and our future front-end. Any user-system data we want access to in our front-end will be copied here and passed on.

Front-end

The folder front contains any code, styles, markup the actual project consists out of.
I devided this folder further like this:

- front
    - logic
    - media
    - sheets
    - styles
    - index.html

Note that you could rename any folder in here to your liking.
The logic folder contains any javascript; media contains any images and svg-icons; styles contains css-files; and sheets... html-files. What for is not for now.

Setup Node

To setup Node you need it installed on your system. Then open a terminal in the root folder of the project.
First of, initialize Node with following command: npm init
Second, open the generated package.json and add/edit the following:

    "main": "main.js",
    "dependencies": {
        "electron": "^21.1.0"
    }

If you want to install some more packages here like Sass or Typescript, that is possible ofcourse.
With this set up, let's install Electron: npm install.

If that succeeded we could start with the next setup, but first I like to add a script to the package to simplify the workflow a bit.

    "scripts": {
        "start": "electron ."
    },

Now, the command npm start would launch Electron. But before this works, we need a body, meaning a backbone and a front.

Setup main.js

As said before, the main.js is like the core of the project. Without, no Electron.
Let's get it set up.

Variables

Firstly the app, BrowserWindow and Menu from electron. These give us the objects necessary to create the app itself.
The path gives us access to the user's directory folders.
Lastly is the process. This object gives us access to the user's system info. And the env object can be used to check if we are in develop-mode.

const { app, BrowserWindow, Menu } = require("electron");
const path = require("path");

const is_mac = process.platform == "darwin";
const is_windows = process.platform == "win32";
const is_linux = process.platform == "linux";

const is_dev = process.env.NODE !== "production";

Now, let's create an object containing the menu of our app. There are some default functions we can use, to use those, use the role key.
The accelerator key indicates a keyboard shortcut.
Here we install a reload functionality, to quickly reload to see new changes in the front-end; and a quit-app functionality, well to fully close the app.

const my_main_menu = [
    {
        label: "App",
        submenu: [
            {
                label: "Quit",
                role: "quit",
                accelerator: is_mac ? "Cmd+W" : "Ctrl+W",
            },
            {
                label: "Reload",
                role: "forceReload",
                accelerator: is_mac ? "Cmd+R" : "Ctrl+R",
            },
        ],
    },
];

Functions:

The create_window function sets up an app window. It takes the name of the file to render there.
As you can see it creates a window with given width and height and title. It is also preloading the preload.js here.
It also checks whether or not we are in develop-mode and opens a chrome devtools if so. The way we create the devtools here is a fix, as we saw in Electron Saga 0".

function create_window(_name) {
    const my_window = new BrowserWindow({
        title: "My Lab",
        width: 1000,
        height: 750,
        webPreferences: {
            contextIsolation: true,
            nodeIntegration: true,
            preload: path.join(__dirname, "preload.js"),
        },
    });

    my_window.loadFile(path.join(__dirname, `./front/${_name}.html`));

    if (!is_dev) return;
    const dev = new BrowserWindow();
    my_window.webContents.setDevToolsWebContents(dev.webContents);
    my_window.webContents.openDevTools({ mode: "detach" });
}

The set_menu function takes an object and creates a menu.

function set_menu(_menu) {
    const M = Menu.buildFromTemplate(_menu);
    Menu.setApplicationMenu(M);
}

Events:

These events trigger when opening the app and closing the app.
For a deepdive, I suggest looking at the documentation.

app.on("ready", () => {
    create_window("index");

    set_menu(my_main_menu);

    app.on("activate", () => {
        if (BrowserWindow.getAllWindows().length === 0) create_window("index");
    });
});

app.on("window-all-closed", () => {
    if (!is_mac) {
        app.quit();
    }
});

First Load

Lets edit the index.html in our front folder to see something; some may notice a new meta-tag; the "http-equiv" is needed for applications.

And to prevent red squibly lines when the chrome-engine doesn't recognize a word, the spellcheck="false" on the tag does wonders.

<!DOCTYPE html>
<html lang="en" spellcheck="false">

<head>
   <meta charset="UTF-8">
   <meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline';" />

   <meta name="viewport" content="width=device-width, initial-scale=1.0">

   <title>My Lab</title>

</head>

<body>
    <h1>Hello World</h1>
</body>

Now we run the command npm start and a new window should open and it should greet us with the Hello World message we set.

Finaly, caught up.
There still is some stuff like the preload.js we need to take a look at, and even further down the line what the sheets folder is for.

The Electron Saga 0️⃣: My First App

Jace — Mon, 10 Oct 2022 16:00:42 +0000

I've always wanted to make a desktop app. ✨
Ever since I started my webdev journey.
But I currently have other projects to finish, and a responsible dev would not start one project before all others are done, right?
Right.

But I am not a responsible dev, so I am building a desktop app now.

~Let's Start: What to make?

Something small, (my other projects are giving me the stink eye already 👀). But not too small, it still has to be usefull.
An app I could use every day, for work; I thought.
But what functions does it need to have? Let's start simple, A todo-list. I have written a webcomponent for todo-lists in Typescript before, should make things a bit easier.
So that is our goal, an app with a todo-function.

What to use?

My knowledge on app-developing is limited to non-existent. I have only worked with web-technologies before, like HTML, CSS, Javascript... So learning a complete new language is not ideal. At least not for a quick sideproject like this, I should say. So I was looking for frameworks that use web-technologies for app-developing; and I found two: Electron and Tauri.

Electron is bigger, slower, but more consistent on different devices, since it carries its own machine to run on (chromium, I believe).
Tauri on the other hand is said to be smaller and faster, because it doesn't carry its own machine and uses one present on the OS. This however has the drawback of it not beeing as consistent.

In the end I did choose Electron, since it has more documentation to work off. Given this is my first project, it's the safer choice. But after this I'll most certainly give Tauri a chance.

So I went in search of a tutorial to start off of and familiarize myself with the framework. I found this one, it's pretty great.

Video by Traversy Media

~Setup

A dev is set up to encounter errors.

I cloned the quick-start directory from Electron's github and spun up my node-js.
No problems there. 🦾

I followed the tutorial to set up the Main frame of the app and everything worked as expected; but after a while this error message appeared in my terminal:

[9532:1010/142156.863:ERROR:gpu_init.cc(521)] Passthrough is not supported, GL is disabled, ANGLE is

Odd, never seen this one. 🧐
When the interwebs didn't return more than a void function would, even after an hour of searching, I gave up. It didn't seem to impact my workflow, so... ¯_(ツ)_/¯.
I did find some other people who got the same error message, all using a different setup and even a different OS; so no fix there.
If anyone knows what might cause this error and how to mend it, by all means, leave a comment.

The Main Frame

I got back to assembling the main frame and got it running without any issue. I could open the app, close the app... But I could not yet inspect the innards of the app.

Since Electron is web-based it is possible to use devtools like you would on a website, which is great for debugging. So I implemented the function to automaticly open the devtools when launching the app:

my_window.webContents.openDevTools();

And it worked... until it didn't.🙀 Once I closed the app and reopened it, the devtools would not show again.

I got stuck. I could not figure out what was going on. From one moment to the next the tools stopped working.
Traversy Media did not seem to get the same issue. So, just me?
"Perhaps Electronmon is acting up, so try disabling that."
"No that isn't it. It doesn't even work just running Electron."
I deleted and restarted the whole project three times, only to get the same issue again and again. The first devtools launch worked, every following failed.

~Got there in the end. 😸

So, sleep helps. After taking a break for the weekend I came back to this function and went straight to the github issues of Electron and found that it was a recurring problem.
This time the interwebs did return something! A workaround:

const dev = new BrowserWindow();
my_window.webContents.setDevToolsWebContents(dev.webContents);
my_window.webContents.openDevTools({ mode: "detach" });

I can't really explain why this works while the other one didn't but it is working now, so let's not touch it.
It's time to set up the front-end of our app...

JS Errors in the Console, with a twist

Jace — Sat, 01 Oct 2022 12:04:38 +0000

Oh no! My site, it's broken!
What ever shall I do? Better open the console to see what's wrong...

It happens

Errors happen, so we have to handdle them. And since javascript has the console-object, most if not all js-developers use it.
Yet having console errors littered around on your site is not great, (I could be wrong but) it might even influence your SEO score in search engines, so some delegating is in order.

Better not flood the user's console

Flooding the console of a regular user with errors and exceptions is rather inefficient and unnecessary. They don't know how to open the developer tools, never mind navigate to the console.
The only thing website-users need to know is whether or not all interactive functions on the site work, that's it. And that can be done by showing just a "Something has gone wrong" message in a nice and well designed pop-up.

But a flood for them is a sip for me.

Yes, developers do use and need the console for first line debugging, users do not.
So let's hide all messages from the console unless a developer visits the site. A dumbed-down developer-mode if you wish.

First, convert all loud errors into silent ones. Use the try-catch block to exit the function early when something goes wrong and show a simple error message to the user. That's better than crashing the whole thread, wouldn't you say?

Great! But now the developer can't assess any errors though. To remedy, let's create our own console function:

const dev_log = ()=>{}

This function is going to pass a message to the console if and only if a condition is met. Otherwise it will exit the function early with return.

const dev_log = (_error) => {
if(!*condition*) return;
console.log(_error);
}

But what condition? You could use any: login, ip-address, local host... Or whatever floats your boat.
I like checking the hash in the url, you know: yoursite.com#hash.
It's the easiest to set up and has no real implications for the website, since the hash is mostly used to highlight articles, or navigate one-pagers.
So let's do that. You can access that hash from the location-object.

const dev_log = (_error) => {
const is_debugging = location.hash == "dev";
if(!is_debugging) return;
console.log(_error);
}

And that's it. Now the only thing left is to call this function every time we try and catch errors;

try {
foo();
}
catch(error){
show_error_to_user();
dev_log(error);
}

Ofcourse you could expand the function to support multiple types of console functions like console.error, console.group or console.time even, make it fit your needs.

So now only visitors using yoursite.com#dev will be able to inspect any errors you logged to the console.
What do you think?

DEV Community: Jace

CSS, The Old

Table of contents

Float Layouts

Padding Aspect Ratio

Pixels Values

Rem

Em

Ch

Break out of the Parent

Remote with FTP

Setup

Download

Upload

Boundaries

In conclusion

The Electron Saga 3️⃣: All beginings have an end.

Frameworks?

Layout

JS

Helper functions;

page_loader class

It works but...

Series Conclusion

The Electron Saga 2️⃣: Bridge building

Build the bridge

Cross the bridge

The Electron Saga 1️⃣: Setup

Folder Structure

First: background noice (mostly)

Next up: Electron

Front-end

Setup Node

Setup main.js

Variables

Functions:

Events:

First Load

The Electron Saga 0️⃣: My First App

~Let's Start: What to make?

What to use?

~Setup

The Main Frame

~Got there in the end. 😸

JS Errors in the Console, with a twist

It happens

Better not flood the user's console

But a flood for them is a sip for me.