DEV Community: abdellah ht

How to Add a Canonical URL to Your dev.to Post

abdellah ht — Thu, 23 May 2024 18:13:21 +0000

Hello dev.to community! 👋

If you're here, you probably already have a few posts under your belt and are familiar with using front matter to add metadata to your dev.to articles. Adding a canonical URL is a crucial step for those of us who cross-post content from our personal blogs or other platforms. It helps with SEO by indicating the original source of your content, ensuring search engines know where the content was first published.

Step-by-Step Guide to Adding a Canonical URL

Open Your Post in the Editor
- Navigate to your dev.to dashboard and open the post you want to edit. If you’re creating a new post, start a new draft.
Access the Markdown Editor
- Make sure you’re in the markdown editor. This is where you’ll add your front matter.
Modify the Front Matter
- At the top of your post, you should already have some front matter in YAML format. This is where you add metadata like the title, description, and tags.
Add the Canonical URL
- Include the canonical_url field in your front matter. Here’s how your front matter should look:

   ---
   title: "Your Post Title"
   published: true
   description: "A brief description of your post"
   tags: programming, tutorial, devto
   canonical_url: "https://yourwebsite.com/your-original-post"
   ---

   Your post content goes here...

Replace https://yourwebsite.com/your-original-post with the actual URL of your original content.

Save and Publish After adding the canonical URL, save your changes and publish your post. This will tell search engines that the original source of the content is the URL you provided, helping to avoid duplicate content issues.

If you liked this post, give it a 🦄 :)

Understanding Git Worktrees: A Solution to Multi-Branch Development

abdellah ht — Thu, 23 May 2024 18:05:26 +0000

Introduction

Imagine you're working on a new feature in a Git repository, and suddenly, you need to switch to another branch to fix a critical bug. You could commit your changes, switch branches, and then switch back, but that's cumbersome and can lead to a messy commit history. Alternatively, you could stash your changes, switch branches, and then apply the stash, but that's not always ideal either.

This is where Git worktrees come in. Git worktrees allow you to check out multiple branches simultaneously, each in its own working directory, without the need for stashing or committing changes.

In this article, we'll explore what Git worktrees are, the problems they solve, how they compare to git stash, and briefly touch on some other alternatives for managing multi-branch development.

Setting Up a Worktree

To create a new worktree, you can use the following commands:

# Create a new worktree for an existing branch
git worktree add ../path/to/new-worktree branch-name

# Create a new worktree and a new branch
git worktree add -b new-branch ../path/to/new-worktree
orktree add <path> <branch>

This will create a new worktree in the specified directory and check out the specified branch. You can now work on the new branch independently of the original worktree.

Comparing Worktrees to Git Stash

Git stash is another popular feature used to save uncommitted changes temporarily. While it serves a similar purpose to worktrees, there are some key differences:

Visibility: Stashed changes are hidden from the working directory, making it easy to forget about them. Worktrees, on the other hand, provide a more visible and structured way to manage multiple branches.
Context switching: With stashes, you need to remember which stash corresponds to which branch. Worktrees provide a more intuitive way to switch between branches.
Workflow: Stashes are more suited for short-term changes that you plan to apply quickly. Worktrees are better for long-term context switching and multi-branch development.

Other Alternatives

While worktrees and stashes are the most common solutions for managing multiple branches, there are a few other alternatives worth exploring:

Besides git stash, there are a few other strategies and tools to manage multi-branch development:

Multiple Clones:

You can clone the same repository into different directories. While this allows simultaneous work on multiple branches, it is highly inefficient in terms of disk space and can lead to synchronization issues.

Git Submodules:

Git submodules allow you to keep a Git repository as a subdirectory of another Git repository. This can be useful for including dependencies but is not ideal for handling multiple branches of the same project.

Git Subtrees:

Git subtrees allow you to merge and split repositories without the need for submodule management. This is useful for including external repositories but does not address the issue of switching between branches within the same project.

Conclusion

Git worktrees are a powerful feature that can significantly improve your multi-branch development workflow.
By allowing you to work on multiple branches simultaneously without the hassle of managing stashes or multiple clones, worktrees provide a cleaner and more efficient way to switch contexts.
If you frequently find yourself juggling multiple branches, consider incorporating worktrees into your Git workflow for a more seamless development experience.

Xcode Tips to Supercharge Your Development Workflow

abdellah ht — Fri, 23 Feb 2024 09:05:00 +0000

If you're an iOS developer, you know how crucial it is to optimize your workflow in Xcode. In this blog post, we'll explore some powerful Xcode tips that can save you time and enhance your development experience.

We'll cover three main categories: file navigation, efficient text editing, and optimizing screen real estate.

Or if you can watch this video if you prefer

File Navigation

1. Quick Open

Use Command + Shift + O to open any file within your project swiftly. You can even specify a line number to jump directly to a particular section of the code.

2. Reveal in Project Tree

When deep within a file, press Command + Shift + J to highlight and reveal the file in the project tree. Option-clicking on a file opens it in a split view.

3. Quick Help

If you're unsure about a code element, Option-click on it to access floating documentation, providing quick insights into its functionality.

4. Go to Definition

Skip the right-click and use Option + Click to jump directly to the definition of a variable or function.

5. Efficient Navigation

Navigate quickly between files using Command + Control + Left/Right Arrow to switch between open files, streamlining your workflow.

Efficient Text Editing

6. Expand Switch Cases

Right-click on a switch statement, select "Refactor," and choose "Expand Switch Cases" to generate cases for all enum values.

7. Documentation Comments

Add documentation comments by using Option + Command + /. This adds a comment block, which is especially useful for generating Quick Help documentation.

8. Indentation

Fix indentation issues with ease. Use Ctrl + I to indent or de-dent a selected block or the entire file. For a single line, use Command + [ / ].

Optimizing Screen Real Estate

9. Customize Layout

Free up space on smaller screens by toggling the right sidebar and project navigator. Resize the debugging area and toggle it using Command + Shift + Y.

10. Toggle Preview Canvas

Hide the preview canvas when unnecessary by clicking the icon or using Command + Option + Return.

Now you're equipped with a set of powerful Xcode tips that cover file navigation, text editing, and screen real estate optimization.

Incorporate these into your workflow to become a more efficient, try to learn the shortcuts one by one

Happy coding :)

Lean on the web platform to validate emails

abdellah ht — Sat, 15 Oct 2022 10:35:28 +0000

Email validation in javascript is a very common topic in the web development world.

The first instinct is to match a string against a Regex, but the Regex can get hairy really fast as it tries to accommodate the whole standard specification for email addresses.

Just take a look at this accepted response on stackoverflow:

const emailRegex =
        /^(([^<>()[\]\.,;:\s@\"]+(\.[^<>()[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i;
const isValild = emailRegex.test(someEmail);

That works but nobody knows why!

The browser has built in form validation for different types of for inputs.

An input with a specified type, in this case type="email", is only valid if it has a valid email address.

This method offloads the validation burden to the browser and surfaces a nice API where the validation question is answered with a simple input.checkValidity().

Example:

function validateEmailHTML(email = "") {
    // create an offscreen input element 
    let input = document.createElement("input");
    // give it the "email" type constraint 💌
    input.type = "email";
    // fill it ✍️
    input.value = email;
    // profit 🎉
    return input.checkValidity();
}

Thanks for your attention!

:wq

master the `rootMargin` option in intersection observer.

abdellah ht — Mon, 06 Jun 2022 16:54:05 +0000

The Intersection Observer API has been around for a few years now and has pretty good browser support.

It has some nice options which can be intimidating or simple depending on what you want to do with it.

In my case, I had a horizontal scrolling list of items in which I wanted to highlight the center most item.

This is the final product.

And this is a video where I go over pretty much the same details:

The first instinct we might have is to use an intersection observer, which is a way for the browser to tell us when some element intersects with (or not) another.



let centerObserver = new IntersectionObserver(
  function (entries) {
    entries.forEach((entry) => {
      if (entry.isIntersecting) {
        entry.target.classList.add("focused");
      } else {
        entry.target.classList.remove("focused");
      }
    });
  },
  // options
  {}
);

Where entries are an array of IntersectionObserverEntry corresponding to the items we tell the observer to observe, like this:



let items = document.querySelectorAll(".item");
items.forEach((item) => centerObserver.observe(item));

when the item is intersecting ie visible, we add a .focused class to it.

But the problem with this observer is that it defaults to observing the items position based with regard to the viewport instead of the container element.

To fix that we can pass the root element options in the second argument to the IntersectionObserver.



// ....
// options
{
  root: document.querySelector(".container");
}

Pretty much there, except that all the items in view getting the .focused class, and this is where the rootMargin option comes to play.

rootMargin enables one to enlarge (or restrict) the span of the area of the container. In this case we want the latter.

Let's say we want restrict the intersection area of the container to the middle 40%, that would be {rootMargin: "0 -30% 0 -30%"}

Notice the negative margin to eat into the container instead of add to it.



let root = document.querySelector(".container");
// the options look so far like this
{ root: root,
  rootMargin: "0 -30% 0 -30%"
}

This still depends on the items fitting within the remaining 40% width and not being bellow 20%, otherwise we would have two focused items.

One possible fix is to use some dynamic dimensions for the rootMargin. What we want is to leave enough (or slightly more) space for one item to intersect.



let itemWidth = items[0].offsetWidth;
let containerWidth = root.offsetWidth;
let marginWidth = (containerWidth - itemWidth) / 2;
//...
{ rootMargin: `0 ${marginWidth}px  0 ${marginWidth}px` }

This will always leave enough space for one item only.

One last problem (last one I promise) is that items in beginning and in the end don't have space to scroll to the midway point, so will never get .focused.

A possible solution is to add a margin-left for the first item and a margin-right for the last item of marginWidth, then fixing the visual offset by adjusting the container's scrollLeft by the same amount.

One of the options of IntersectionObserver is threshold which is how much of the item should be visible to be considered isIntersecting, it defaults to 1 ie 100%
but it would be nice if the item got highlighted as soon as it takes more space in the area of interest than any other item, so I added {threshold: 0.51}.
That is once it has at least 51% shown, it gets focused.

The full snippet is in the embedded Codepen.

I hope you learned something new and saved some time.

Thank you for reading, don't forget to like and follow for more.

Solve nvim lsp denols vs tsserver clash

abdellah ht — Sun, 05 Jun 2022 23:39:28 +0000

Recently I started using Deno for some personal projects, and when I installed the Deno lsp client on neovim, it clashed with tsserver as it has no idea what Deno types are and some other annoying diagnostics.

The official documentation instructs you to specify the root_dir param in the server:setup(options), but I thought that was a lot of hassle as it would not work for when you don't have a Deno project, but have no package.json either.

My solution was to use a programmatic way to have fine grained control over when to start which. Basically when tsserver wants to start, it checks if denols is in the active clients (which you can get using vim.lsp.get_active_clients()) and not continue setup, and denols does the same check to see if tsserver is attached to a file that belongs to it and kills it.

here's the full snippet:

      local active_clients = vim.lsp.get_active_clients()
      if client.name == 'denols' then
        for _, client_ in pairs(active_clients) do
          -- stop tsserver if denols is already active
          if client_.name == 'tsserver' then
            client_.stop()
          end
        end
      elseif client.name == 'tsserver' then
        for _, client_ in pairs(active_clients) do
          -- prevent tsserver from starting if denols is already active
          if client_.name == 'denols' then
            client.stop()
          end
        end
      end

I hope it saves you some time.

Parallel promise execution: Beyound Promise.all()

abdellah ht — Thu, 31 Mar 2022 11:42:59 +0000

In this post, I will talk about running promises in parallel and optimizing for the lowest waiting time possible.

When you have a bunch of promises that need to execute sequentially, you
just run them in a sequence usein .then() or awaits:

getUser()
    .then((user) => getPosts(user.id))
    .then((posts) => use(posts));

// Or

let user = await getUser();
let posts = await getPosts(user.id);
use(posts);

But when they don't depend on each other like the posts that need the user id,
you can run them in parallel using Promise.all().

let [value1, value2, valueN] = await Promise.all([promise1, promise2, promiseN]);

Which accepts an array of an arbitrary number of promises and returns a promise with all the valuse
once each of them is resolved.

If one of them fails, the whole things rejects with the first error that occured.

One possible solution to prevent the whole thing from failing would be to chain the promiseN in
the array with a .catch() which will make it always resolve no matter. The problem that arrises
is how to detect if the valueN we get on the other side is from its resolution or rejection.

A possible solution would be to always return a tuple or an object from these promises.

Example:

const wrap = (promise) => promise.then((value) => ({ error: null, value })).catch((error) => ({ error }));

With this utility in hand, we can inspect the valueN on the other side to see if it was a success or not,
and there's still room for sophisticaiton to return more metadata for retrying purposes.

const wrappedPromises = [promise1, promise2, promiseN].map((promise) => wrap(promise));
let values = await Promise.all(wrappedPromises);

What about when the array of promises is huge (by whatever definition makes sense for your application),
maybe you're running some resource intensive processes and don't want to exceed 10 at a time?

The answer is chunking, you could use something like lodash.chunk or roll your own.

let chunks = _.chunk(arrayOfPromises, 10);

for (let chunk of chunks) {
    let chunkValues = await Promise.all(chunk.map(wrap));
    use(chunkValues);
}

This was part of a recent optimization job I did for a client, I hope you found it as helpful as I did.

If you enjoyed this post, don't forget like and follow for more.

:wq

Use Typescript generics for a type safe `setTimeout` and `setInterval`

abdellah ht — Sun, 20 Mar 2022 12:46:57 +0000

TLDR;

Here's the code:



type Handler = ((...args: any[]) => any) | string;

function safeSetTimeout<F extends Handler>(
    handler: F,
    timeout?: number,
    ...args: F extends string ? any[] : Parameters<F extends string ? never : F>
) {
    return setTimeout(handler, timeout, ...args);
}

If you understand everything in the following snippet, you don't have much to gain from this post.
But you might want check out the practical snippet at the end of this post.

Otherwise, stick around and let's produce some stricter variants of your loved setTimeout and setInterval.

The problem

If you check the type definitions
for timers in Typescript, you will find this:



type TimerHandler = string | Function;
setInterval(handler: TimerHandler, timeout?: number, ...arguments: any[]): number;
setTimeout(handler: TimerHandler, timeout?: number, ...arguments: any[]): number;

The first thing this reminds us of is that these timers can take 3+ arguments, most of us are used to passing only two. The delay/interval
and some callback.

The TimerHandler definition also says that it can be a string, which gets eval()ed and executed.

I'm pretty sure you had the lecture of evil eval elsewhere, so I will not bore you with it here. But it is still interesting from
a type point of vue as the type system has no way of deducing what an arbitrary string might do. So nothing to do in this regard.

The third argument and beyond get passed to the handler upon invocation. But their types and and the types that the handler
expects are completely unrelated, those any and Function are so loosy goosy.
You could pass cabbage to a function that expects a number and typescript will still be happy.

Let's change that!

The solution

We want a way to link the type of a callback function's arguments to whatever other arguments gets passed to the caller.

For example, this apply higher order function takes in a callback from string to number and string as arguments
and gives us back the result of the application of that callback, which Typescript accurately infers as a number.



const apply = (callback: (x: string) => number, arg: string) => callback(args);

But what if we want to make the callback's input arbitrary, after all, all that apply cares about is that arg matches
the input of callback

Enter generics. We can tell Typescript, hey, see this T ? I will give you a callback that consumes it and a corresponding arg.



const applyGeneric = <T>(callback: (x: T) => number, arg: T) => callback(arg);

And when we use it like this, we get a compilation error:



const exclaim = (x: string, times = 1) => x + '!'.repeat(times);
// Argument of type '(x: string) => string' is not assignable to parameter of type '(x: string) => number'.
//  Type 'string' is not assignable to type 'number'.
applyGeneric(exclaim, 0);

Typescript is not happy as the 0 "constrains" T to be a number and exclaim consumes Ts of type string.

What about a generic return type of callback? easy enough. Just add another generic parameter.



const applyGeneric = <T, R>(callback: (x: T) => R, arg: T) => callback(arg);
// Argument of type 'number' is not assignable to parameter of type 'string'.
applyGeneric(exclaim, 0);

And as nice side effect, notice the more specific compile error message from the previous example.

So far so good, but what if we have more than one argument to pass to callback ?
We could just other generic parameters to apply and overloads. But it gets ugly fast.

Luckily, Typescript enables us to have the type of a functions arguments using the Parameters utility type,
which is generic over a function type and gives us the type of its parameters as tuple type.

A function's type is essentially its signature. In this example, Params1 and Params2 are equivalent to the tuple type Params3.



const exclaim = (x: string, times = 1) => x + '!'.repeat(times);
type Params1 = Parameters<(x: string, times?: number) => string>;
type Params2 = Parameters<typeof exclaim>;
type Params3 = [x: string, times?: number];

And the return type ? we have ReturnType<F> for that in a similar manner.

With this mind, let's get back to applyGeneric:



const applyGeneric = <F extends (...args: any[]) => any>(callback: F, ...args: Parameters<F>): ReturnType<F> => {
    return callback(...args);
};

We have the extends keyword here, it's used to place a "constraint" on F so that it only accepts functions.
And F is used to tell the compiler that the type of callback is the same as the thing we passed to Parameters.

This function is so versatile you can throw any callback to it with any number of arguments and it will just work.

In essence, setTimeout and setInterval are higher order functions similar to our applyGeneric, but we don't have to worry about
the return type as it is already known. So a simple implementation would look like this:



const safeSetTimeout = <F extends (...args: any[]) => any>(callback: F, timeout?: number, ...args: Parameters<F>) => {
    return setTimeout(callback, timeout, ...args);
};

const safeSetInterval = <F extends (...args: any[]) => any>(callback: F, timeout?: number, ...args: Parameters<F>) => {
    return setInterval(callback, timeout, ...args);
};

This will work for all intents and purposes, and it will force you to not pass in a string for the callback.

But if you really want to make the signatures identical, then any will creep in when you use a string for callback.

So coming back full circle to the snippet at the beginning of the post, the only difference from this implementation is
the use of type conditionals to revert back to the original behavior when callback is a string

Does it all make sense now ? Do you find yourself using arguments beyond timeout to timers ?

Please let me know what you think, ask questions and suggest future topics I should cover in future posts in the comments below.

Thank you for reading, I hope you found this post helpful, don't forget to follow for more 🤗.

Promises: async/await vs .then(), how we got here and why I use both

abdellah ht — Sat, 19 Mar 2022 13:44:25 +0000

How we got here

Promises marked a huge turning point in async js, they enabled a new type of control flow that saved us from callback hell. But some people found that calling .then() multiple times was too much, too callbacky.

Then after a while, we resorted to generator functions and cogenerators, which made async code feel like its synchronous, at the cost of wrapping it in a generator function, yielding every line and introducing a cogenerator library (for example co) to deal with unwrapping the promises like the following example, where we could just yield a promise whenever we encounter it and pretend that the yield does not exist on that line of code.

co(function* () {
  let result1 = yield somePromise1
  let result1 = yield anotherPromise
  dostuff(result1, result2)
})

This evolution served as the inspiration of the async/await syntax introduced in es7, and finally we could just

let value = await somePromise
doStuff(value)
// instead of
somePromise.then(value => doStuff(value)

Oh, and you had to wrap it in an async function to be able to use it, but that's changing with top level await.

Why I use both

One simple reason: error handling.

Writing code for the happy path feels good, if only the world were a perfect place. But hélas, if you omit error handling during development, you will pay for it later while digging through a mysterious bug report.

Promises have a .catch(callback) method similar to .then(callback) where the callback expects an error.

myPromise
    .then(value => handleHappyPath(value))
    .then(value2 => handleAnotherHappyPath(value2))
    .catch(err => handleError(err))

The async/await version looks like this:

try {
    let value = await myPromise
    let value2 = await handleHappyPath(value)
   handleAnotherHappyPath(value2)
} catch(err) {
    handleError(err)
}

One least used - but very useful - feature of .then is that it accepts a second parameter as an error handler.

myPromise
    .then(handleHappyPath, handleErrorScoped)
    .then(anotherHappyPath)
    .catch(err => handleError(err))

In this example, handleErrorScoped will take care of errors for this particular step. While handleError will handle errors of the whole chain (including errors inside handleErrorScoped).

The equivalent sync/await version requires a nested try/catch block.

try {
    let value
    try {
        value = await myPromise
    } catch (err) {
        // possibly setting `value` to something
        handleErrorScoped(err)
    }
    let value2 = await handleHappyPath(value)
   handleAnotherHappyPath(value2)
} catch(err) {
    handleError(err)
}

Maybe it's just me, but I find the latter a hell of lot more verbose, running away from callback hell, ran directly into try/catch hell.

An example of an instance where I found myself combining both is when I use puppeteer to check if an element exists in a page.

let hasElement = await page.evaluate(() => document.querySelector("some selector"))
    .then(() => true)
    .catch(() => false)

Conclusion

async/await was a huge stepping stone towards simplifying async javascript, but it does not obsolete .then() and .catch(), both have their use cases, especially when
we need granular control over error handling.

A combination of both seems to give the most readable code, robust and maintainable code.

If you made it this far, please show your support with reactions and don't hesitate to
ask question within comments, I'd love to answer each one of them and know your thoughts about the dichotomy of async/await vs .then() 🙂

Promises: run any promise with a timeout

abdellah ht — Fri, 18 Mar 2022 15:11:44 +0000

A promise has two states: either pending or settled (resolved or rejected). The user has no control over the time it takes from going from the first state to the second. Which makes it harder to bail out on a certain promise when it takes too long in a promise friendly way.

Promise.race() to the rescue.

How does `Promise.race` work

This method takes an array of promises and - as its name suggests - races them, the first one to be settled in either state wins.

example:

const resolveAfter = (duration, value) => new Promise((resolve, reject) => setTimeout(() => resolve(value), duration));

let first = resolveAfter(100, 'value from first');
let second = resolveAfter(200, 'value from second');

Promise.race([first, second]).then(console.log);
// logs 'value from first'

And it works with errors too as you might expect:

const resolveAfter = (duration, value) => new Promise((resolve, reject) => setTimeout(() => resolve(value), duration));
const rejectAfter = (duration, err) => new Promise((resolve, reject) => setTimeout(() => reject(err), duration));

let first = rejectAfter(100, new Error('oops in first'));
let second = resolveAfter(200, 'value from second');

Promise.race([first, second]).then(console.log).catch(console.error);
// logs: 'Error: oops in first'

Leverage `Promise.race` to race promises against the clock

The fisrst ingredient is a promise that resolves after a timeout. We have already seen that in the previous example.

The second is a specific Error class to be sure it came from the rejected timeout and not the original promise we were awaiting.
We could implement a specific class that extends Error like this:

class TimeoutError extends Error {
    constructor(...args) {
        super(...args);
    }
}

const resolveAfter = (duration, value) => new Promise((resolve, reject) => setTimeout(() => resolve(value), duration));
const rejectAfter = (duration, err) => new Promise((resolve, reject) => setTimeout(() => reject(err), duration));

let first = rejectAfter(100, new TimeoutError('Timeout!'));
let second = resolveAfter(200, 'value from second');

Promise.race([first, second])
    .then(console.log)
    .catch((err) => {
        if (err instanceof TimeoutError) {
            // handleTimeoutError(err)
        } else {
            // handleOtherError(err)
        }
        console.error(err);
    });

// logs: Error: Timeout!

You could imagine moving this logic to its own module and abstracting away the timout logic like this:

// module: timeout.js

const rejectAfter = (duration, err) => new Promise((resolve, reject) => setTimeout(() => reject(err), duration));

export class TimeoutError extends Error {
    constructor(...args) {
        super(...args);
    }
}
export const withTimeout = (promise, timeout = 0) => {
    return Promise.race([promise, rejectAfter(100, new TimeoutError('Timeout!'))]);
};

// module: user.js

import { withTimeout, TimeoutError } from './timeout';

const resolveAfter = (duration, value) => new Promise((resolve, reject) => setTimeout(() => resolve(value), duration));

withTimeout(resolveAfter(200, 'value from my promise'), 100).then(console.log).catch(console.error);
// logs: Error: Timeout!
withTimeout(resolveAfter(100, 'value from my promise'), 200).then(console.log).catch(console.error);
// logs: value from my promise

Conclusion

I hope you have found this short article helpful. Promise.race() doesn't get a lot of love, but we leveraged it
to solve a commnon question amongst promise users.

If you have any remarks or questions, please leave them in the comments. I will be happy to answer each one of them.

And don't forget to follow for more 🤗

ftp auto upload files on change

abdellah ht — Sat, 20 Feb 2021 19:34:45 +0000

Hello world, this is my first post on dev.

Today we're going to see how to watch files for change and upload them automatically to an ftp server using node.js. This is a real world project that I worked on for a client.

This article is intentionally short, feel free to open the code on this repo in second tab to follow along.

Let's think about the problem for a sec, we have 3 sub-problems:

First we need a way to be notified when a certain file changed.
Second we need to figure out how to upload a file to an ftp server.
And last we will tie out all together and throw in some polish for a reliable end product.

A quick look at the native fs module reveals that we have the method fs.watch(directory, watchHandler) where the watch handler takes two arguments (event, fileName) =>{...} and event is either change or rename, we are mostly interested in change here. This takes care of the first sub-problem.

For the second sub-problem, I used the polished ssh2-sftp-client npm package. Which has many great features, but we're interesting in uploading files, so it's basically connect -> upload file.

The requirement for the source and destination folders needed to be specific for each file of interest. The simplest solution I found for this is a plain text file with each file on one line relying on the order of the items to represent the credentials for the ftp server and the folders. Further details are on the example config.txt, but it essentially looks like this:
filname username host port password source_folder destination_folder.

So to answer the third sub-problem, the general flow is like this:

Read the files from the config.txt file
massage the data to correspond to objects we can use down the line.
create file watches for each folder and source folders and respond to change events when they concern a file from the watched files, and of course some light logging to inform the user about what's going on.

I hope you feel like you've learned something new. Don't forget check the code on github and comment any suggestions/questions you might have.

DEV Community: abdellah ht

How to Add a Canonical URL to Your dev.to Post

Step-by-Step Guide to Adding a Canonical URL

Understanding Git Worktrees: A Solution to Multi-Branch Development

Introduction

Setting Up a Worktree

Comparing Worktrees to Git Stash

Other Alternatives

Multiple Clones:

Git Submodules:

Git Subtrees:

Conclusion

Xcode Tips to Supercharge Your Development Workflow

File Navigation

1. Quick Open

2. Reveal in Project Tree

3. Quick Help

4. Go to Definition

5. Efficient Navigation

Efficient Text Editing

6. Expand Switch Cases

7. Documentation Comments

8. Indentation

Optimizing Screen Real Estate

9. Customize Layout

10. Toggle Preview Canvas

Lean on the web platform to validate emails

master the `rootMargin` option in intersection observer.

Solve nvim lsp denols vs tsserver clash

Parallel promise execution: Beyound Promise.all()

Use Typescript generics for a type safe `setTimeout` and `setInterval`

TLDR;

The problem

The solution

Promises: async/await vs .then(), how we got here and why I use both

How we got here

Why I use both

Conclusion

Promises: run any promise with a timeout

How does Promise.race work

Leverage Promise.race to race promises against the clock

Conclusion

ftp auto upload files on change

How does `Promise.race` work

Leverage `Promise.race` to race promises against the clock