DEV Community: Ionel Cristian Lupu

IP to Country Detection with GeoPulse.pro

Ionel Cristian Lupu — Wed, 12 Feb 2025 12:51:10 +0000

Do you want to show the user’s country flag, currency, language, or auto-select their country’s phone prefix in the checkout form?

For example, amazon.com does it on their website. They automatically preselect your delivery country, language, and currency:

When building web applications, understanding your user’s location can enhance the experience by customizing content, languages, or services.

Many services provide this information about your users, but most of them sell you cloud API access with limited API requests for a small price, or unlimited requests for a huge price.

That’s why I built GeoPulse, which gives you offline access to an IP database, eliminating the need for a third-party API. No requests limit. No latency.

In this blog post, I’ll walk you through how to get started with GeoPulse and use it to retrieve your user’s information.

Getting Started

With GeoPulse, you have two options: offline database mode (highly recommended for independence from cloud APIs) or cloud API (faster to implement, but defeats the purpose).

In this post, we’ll implement the offline method, allowing you to run your own server with simple endpoints to retrieve user information based on their IP. This server can run on the same machine as your backend, ensuring zero network delays, since you’re not relying on an external cloud API. When you call it, you will get a response similar to this:

Currently, some fields (city name, latitude, longitude) are unavailable but will be added soon!

Step 1: Sign Up and Get Your API Key

To use GeoPulse, head over to the website and create an account. Once logged in, you can get your free API key from the dashboard. This key will be needed to get access to the GeoPulse database.

Step 2: Download the GeoPulse server

This is an easy step. Go to the docs page and search for the command that lets you download the binaries for the server.

Or, if you prefer, you can even go to the Github page and create your own binaries from the source code. It’s open source.

Here are some examples:

# for linux arm
curl -L https://github.com/GeoPulseData/pulse/raw/main/binaries/GeoPulse-linux-arm -o geopulse

# for macOS arm
curl -L https://github.com/GeoPulseData/pulse/raw/main/binaries/GeoPulse-macos-arm -o geopulse

# for Windows
curl -L https://github.com/GeoPulseData/pulse/raw/main/binaries/GeoPulse-windows.exe -o geopulse

Once you have the program, remember to change the execution permissions on it so we can actually run it (might not be needed for Windows):

chmod +x ./geopulse

And now we are ready to run it. Use your API Key you got from the GeoPulse Dashboard page:

./geopulse --key=123abcd-some-other-characters-here

You should then see some files being downloaded and your server started. By default, it starts on port 8090, but you can change that. Now, we can get any IP, feed it to the /ip endpoint and get a JSON back. For example, here is the data for the Google servers IP http://localhost:8090/ip/8.8.8.8:

{
    "ip": "8.8.8.8",
    "latitude": "coming soon",
    "longitude": "coming soon",
    "isMobile": "coming soon",
    "city": "coming soon",
    "state": "coming soon",
    "zip": "coming soon",
    "country": {
        "name": "United States",
        "code": "US",
        "capital": "Washington, D.C.",
        "callingCode": "+1",
        "isEUMember": false,
        "currency": {
            "code": "USD",
            "name": "United States dollar",
            "symbol": "$"
        },
        "flag": {
            "png": "https://flagcdn.com/w320/us.png",
            "svg": "https://flagcdn.com/us.svg",
            "emoji": "🇺🇸"
        },
        "continent": {
            "name": "North America",
            "code": "NA"
        },
        "language": {
            "name": "English",
            "code": "eng"
        }
    },
    "timeZone": {
        "name": "coming soon",
        "localTime": "coming soon",
        "localTimeUnix": "coming soon"
    },
    "exchangeRateBaseCurrency": "USD",
    "exchangeRate": 1
}

You can customize the baseCurrency if you want like this:

http://localhost:8090/ip/8.8.8.8?baseCurrency=EUR

The baseCurrency parameter lets you change the exchangeRateBaseCurrency. For example, baseCurrency=EUR will return exchange rates between the user’s country currency (USD in this case) and EUR. This allows you to dynamically adjust prices based on the user’s location, converting from EUR (or any currency of your choice) to users’ currency (USD in this case).

Some feedback about the service will be much appreciated!

Personal Website: https://ionel-lupu.com/
Geopulse: https://geopulse.pro/
Twitter: Ionel Lupu

Async/Await Traps: The importance of await in try/catch blocks

Ionel Cristian Lupu — Tue, 12 Sep 2023 06:30:26 +0000

Is the following code going to crash your program or will it execute without any issues? Take your time to make a guess.

async function canParkCar(car) {
    if ( !car.allowed ) {
        throw new Error(`${car.owner} is not allowed to park`)
    }

    // some async work

    return true
}

function parkCar(car) {
    try {
        return canParkCar(car)
    } catch ( error ) {
        console.log(error.message)
        return false
    }
}

const car1Parked = await parkCar({ owner : 'John', allowed : false })
if ( car1Parked ) {
    console.log(`car 1 parked`)
}

const car2Parked = await parkCar({ owner : 'Mark', allowed : true })
if ( car2Parked ) {
    console.log(`car 2 parked`)
}

I was confused to see it's actually crashing EVEN if there is a try/catch block intended to handle any thrown errors:

$ node app.js

file: ./app.js:3
        throw new Error(`${car.owner} is not allowed to park`)
              ^
Error: John is not allowed to park

My expectation was to see this in the console:

$ node app.js

John is not allowed to park
car 2 parked

One thing you need to be careful regarding try/catch blocks and promises is to properly use the await keyword
depending on where you want to catch the errors.
In the example above, at this line

return canParkCar(car)

the parkCar function finished its job by just
returning a promise. The promise wasn't resolved, so no error was thrown.

However, when you use await on this line

await parkCar({owner: 'John', allowed: false})

you are now waiting for the promise to resolve and implicitly waiting for any thrown errors. And because there is
no try/catch block around this await statement, the program crashes. The error bubbled up until the "root" of the
program.

The fix? Just await the canParkCar call:

async function parkCar(car) {
    try {
        return await canParkCar(car)
    } catch ( error ) {
        console.log(error.message)
        return false
    }
}

Now, the line

return await canParkCar(car)

not only returns a promise, but it also waits for the promise to resolve. Any thrown errors will be handled there by
the try/catch block.

The program now has the expected output without any crashes:

$ node app.js

John is not allowed to park
car 2 parked

The key takeaway? Be careful when you want to return a promise, or you want to actually resolve it depending on
your try/catch blocks.

That's it for this quick tip.

My Website: https://ionel-lupu.com/
My Twitter: https://twitter.com/ionelLupu_

'onSticky' Event hook in React

Ionel Cristian Lupu — Mon, 26 Jun 2023 17:22:39 +0000

In the previous article we discussed creating a custom event handler for the "element is sticky" event, which allowed us to do change the style of some elements, giving us this effect:

In this article we will take that knowledge and create a custom React hook for handling the "element is sticky" event.

TLDR, give me the code. I don't need the explanation:

function useSticky() {
    const ref = useRef<HTMLDivElement>(null)

    const [isSticky, setIsSticky] = useState(false)

    useEffect(() => {
        if (!ref.current) {
            return
        }

        const observer = new IntersectionObserver(
            ([event]) => setIsSticky(event.intersectionRatio < 1),
            {threshold: [1], rootMargin: '-1px 0px 0px 0px',}
        )
        observer.observe(ref.current)

        return () => observer.disconnect()
    }, [])

    return {ref, isSticky}
}

// in your component

function MyPageComponent() {

    const {ref, isSticky} = useSticky()

    return (
        <div ref={ref} className={`${isSticky ? 'someClass' : ''}`}>
            {isSticky ? 'I am sticky' : 'I am not sticky'}
        </div>
    )
}

Looks rather similar with the vanilla one, but let's get into the explanation. There are some important differences.

Going from vanilla to React

You can almost take the exact same vanilla function and use this directly in a React component like this:

function MyPageComponent() {
    onSticky('.searchContainer', isSticky => {
        document.querySelector('.searchContainer')?.classList.toggle('stickyContainer', isSticky)
    })

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div className="searchContainer">
                my sticky content
            </div>
        </div>
    )
}

But it won't work. This is because the onSticky function runs before any HTML is rendered on the page, making the code not find the element you are looking for.

To solve this issue, we can use the useEffect hook with no dependencies which will be called once, after the first render of the component:

function MyPageComponent() {
    useEffect(() => {
        onSticky('.searchContainer', isSticky => {
            document.querySelector('.searchContainer')?.classList.toggle('stickyContainer', isSticky)
        })
    }, [])

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div className="searchContainer">
                my sticky content
            </div>
        </div>
    )
}

Now, you probably noticed we are still using the native Javascript way of changing the classes of our elements. This is not wrong, but to preserve the consistency of a project that uses React, let's use the React's features instead. The React way is to add dynamic classes directly in the JXS code similar to <div className={isSticky ? 'someClass' : ''}></div> where isSticky is just a boolean that will tell us if an element is sticky or not at the top of the screen.

Let's create some state for this boolean and use our callback to change its value:


function MyPageComponent() {

    const [isSticky, setIsSticky] = useState(false)

    useEffect(() => {
        onSticky('.searchContainer', isStickyValue => {
            setIsSticky(isStickyValue)
        })
    }, [])

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div className={`searchContainer ${isSticky ? 'stickyContainer' : ''}`}>
                my sticky content
            </div>
        </div>
    )
}

By adding the isSticky state in our code, we are able to remove the native Javascript class toggle code and use the isSticky variable to add or remove the stickyContainer class on our element.

Quick refactor: Since we are only calling setIsSticky(isStickyValue) in the onSticky handler, we can refactor it to this: onSticky('.searchContainer', setIsSticky) to make the code a bit shorter.

Going deeper

Fixing the memory leak

So far this looks pretty clean. We still have the same problem as we found in the previous article: the memory leak. If we were to use this code in a component that is removed and rendered many times, it will register the observer many many times, for each re-render. In order to fix this issue we need to unobserve our element once the main component is "destroyed". We can use the destructure feature of the useEffect to unobserve the element:

function MyPageComponent() {

    const [isSticky, setIsSticky] = useState(false)

    useEffect(() => {
        const sticky = onSticky('.searchContainer', setIsSticky)

        return () => sticky?.observer.unobserve(sticky?.element)
    }, [])

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div className={`searchContainer ${isSticky ? 'stickyContainer' : ''}`}>
                my sticky content
            </div>
        </div>
    )
}

Creating the custom hook

Now, we can keep this functionality as is, but we will always write the same boilerplate code when multiple sticky elements are in the project. Let's look at an example with two sticky elements:

function MyPageComponent() {

    const [isSticky, setIsSticky] = useState(false)
    const [isAnotherSticky, setIsAnotherSticky] = useState(false)

    useEffect(() => {
        const sticky = onSticky('.searchContainer', setIsSticky)
        const anotherSticky = onSticky('.anotherSearchContainer', setIsAnotherSticky)

        return () => {
            sticky?.observer.unobserve(sticky?.element)
            anotherSticky?.observer.unobserve(anotherSticky?.element)
        }
    }, [])

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div className={`searchContainer ${isSticky ? 'stickyContainer' : ''}`}>
                my sticky content
            </div>
            <div className={`anotherSearchContainer ${isAnotherSticky ? 'anotherStickyContainer' : ''}`}>
                another sticky content
            </div>
        </div>
    )
}

It doesn't look that bad, but we can do better. Let's extract the useEffect in our custom hook. This should clean our component a bit:

function useSticky(selector: Parameters<typeof onSticky>[0]){
    const [isSticky, setIsSticky] = useState(false)

    useEffect(() => {
        const sticky = onSticky(selector, setIsSticky)

        return () => sticky?.observer.unobserve(sticky?.element)
    }, [selector])

    return isSticky
}

function MyPageComponent() {

    const isSticky = useSticky('.searchContainer')
    const isAnotherSticky = useSticky('.anotherSearchContainer')

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div className={`searchContainer ${isSticky ? 'stickyContainer' : ''}`}>
                my sticky content
            </div>
            <div className={`anotherSearchContainer ${isAnotherSticky ? 'anotherStickyContainer' : ''}`}>
                another sticky content
            </div>
        </div>
    )
}

This looks a lot better. We can now easily write and read what elements are sticky because the code is only one line.

Using refs instead of class names

One other improvement to make is to use React element references (refs) in order to not depend on having a class name on our element. In this case, a ref's value will be the same as having an element returned by document.querySelector method, but without using a class name:

function useSticky(){
    const ref = useRef<HTMLDivElement>(null)
    const [isSticky, setIsSticky] = useState(false)

    useEffect(() => {
        if(!ref.current){
            return
        }
        const sticky = onSticky(ref.current, setIsSticky)

        return () => sticky?.observer.unobserve(sticky?.element)
    }, [])

    return {isSticky, ref}
}

function MyPageComponent() {

    const container = useSticky()
    const anotherContainer = useSticky()

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div ref={container.ref} className={`${container.isSticky ? 'stickyContainer' : ''}`}>
                my sticky content
            </div>
            <div ref={anotherContainer.ref} className={`${anotherContainer.isSticky ? 'anotherStickyContainer' : ''}`}>
                another sticky content
            </div>
        </div>
    )
}

As you can see, we don't need the searchContainer and anotherSearchContainer classes names anymore.

This final hook looks almost the same as the example in the TLDR section. The only difference is that the TLDR example has the onSticky function written directly, inline, in the hook.

Going even deeper

In our last example with refs, we introduced a small issue. If we inspect the Typescript type of the "ref" we will see it has the HTMLDivElement as its generic. Which means we can use our hook only on div HTML tags. This is not a problem when using class names, but if you want to keep the hook with ref, you might run into issues when you want to make some other HTML tag sticky: headings, paragraphs, spans, etc.

The fix is quite simple: let the developer choose the type of the element by making our hook accept a generic:

function useSticky<Target extends HTMLElement>(){
    const ref = useRef<Target>(null)
    const [isSticky, setIsSticky] = useState(false)

    useEffect(() => {
        if(!ref.current){
            return
        }
        const sticky = onSticky(ref.current, setIsSticky)

        return () => sticky?.observer.unobserve(sticky?.element)
    }, [])

    return {isSticky, ref}
}

function MyPageComponent() {

    const container = useSticky<HTMLDivElement>()
    const anotherContainer = useSticky<HTMLSpanElement>()

    return (
        <div style={{height: 5000}}> {/* just so we can scroll a bit */}
            <div>Some header</div>
            <div ref={container.ref} className={`searchContainer ${container.isSticky ? 'stickyContainer' : ''}`}>
                my sticky content
            </div>
            <span ref={anotherContainer.ref} className={`anotherSearchContainer ${anotherContainer.isSticky ? 'anotherStickyContainer' : ''}`}>
                another sticky content
            </span>
        </div>
    )
}

Notice now we used a span for the second sticky container whereas it wasn't possible with our previous hook setup.

You can argue this looks a bit worse that the "class name" example above, but I will leave the decision to you about what version to use.

Conclusion

Making elements sticky is usually straight forward, but if you keep an eye on the details, things might get complicated.

I believe we learned a lot of things in this article:

using vanilla Javascript in React
protecting against memory leaks
did some quick refactoring
used React refs
and fixed the Typescript types.

Overall, a complex journey which improved our knowledge more than just making sticky elements.

That's it from my side. See you in the next one where I will be building a similar event handler in Angular, then Vue.

Website: https://ionel-lupu.com/
Twitter: Ionel Lupu

Crafting an 'onSticky' Event Handler

Ionel Cristian Lupu — Mon, 19 Jun 2023 15:46:27 +0000

Have you ever wished to change the CSS properties when an element goes in the "sticky" mode on the page?

In this article we will be building an onSticky event handler that will trigger a callback when an element goes in and out of "sticky" mode, enabling us to do things like changing the CSS properties of that element.

We will build something similar to this:

TLDR; If you don't wanna bother with the details, here is the code snippet:

function onSticky(selector: string, callback: (isSticky: boolean) => void) {
    const element = document.querySelector(selector)

    if (!element) {
        return
    }

    const observer = new IntersectionObserver(
        ([event]) => callback(event.intersectionRatio < 1),
        {threshold: [1], rootMargin: '-1px 0px 0px 0px'}
    )
    observer.observe(element)

    return {observer, element}
}

Now, making an element sticky on the page is pretty straightforward: you just add the position: sticky and the top, bottom, left or right position CSS properties on your element.

For example, this will make your element stick at the top of the page:

<div style="position: sticky; top: 0;">
    my sticky content
</div>

You can also make it stick at the bottom of the page:

<div style="position: sticky; bottom: 0;">
    my sticky content
</div>

Or, why not both:

<div style="position: sticky; top: 0; bottom: 0;">
    my sticky content
</div>

But in some cases, you want to change the CSS properties of the sticky element when it sticks on the page. In my case, the search component had to stretch to fill the entire width of the screen.

This can be easily achieved using the IntersectionObserver (more info here) to check if an element goes in and out of the "sticky mode".

In truth, to achieve our goal we'll be implementing a clever workaround. Keep reading to discover how we make this happen.

The code

As you already saw, here is the function:

function onSticky(selector: string, callback: (isSticky: boolean) => void) {
    const element = document.querySelector(selector)

    if (!element) {
        return
    }

    const observer = new IntersectionObserver(
        ([event]) => callback(event.intersectionRatio < 1),
        {threshold: [1], rootMargin: '-1px 0px 0px 0px'}
    )
    observer.observe(element)
    return {observer, element}
}

The explanation

This function takes the CSS selector of the element you want to make sticky and a callback that is called whenever the element goes in and out of the sticky mode. The IntersectionObserver takes two arguments:

the handler which is called whenever the threshold is crossed, and
a configuration object where you can specify the threshold and some other properties

The threshold (a number between 0 and 1) indicates at what percentage of the element's visibility the observer's callback should be executed. All right, this sounds complicated. But basically the callback will be triggered once when the element goes at a bit off screen and once when it gets back on the screen.

Now, you may wonder what is the rootMargin: '-1px 0px 0px 0px' about. This is "tricking" the browser to see the element be top: -1px. Why do we need it? Let's analyse the situation without it.

As I said above, the callback of the IntersectionObserver will be called when the element goes a bit off screen. Having top: 0 with position: sticky will make the element be 100% visible on the screen thus never making the IntersectionObserver call the callback.

Adding rootMargin: '-1px 0px 0px 0px' will be used in calculating the position of the element making it seem the element is 1px off screen at the top. It won't change the position's margin on the page.

Adding animations

Now, having this event ready, we can use it to change some CSS classes on our elements. Here is the code from the first image:

In this example, I added a container around my search component. This allows me to have two different widths: a small width for the "non sticky" mode and full width for the "sticky mode".

With the onSticky event's callback, I can control which classes to toggle:

onSticky('.searchContainer', isSticky => {
    document.querySelector('.searchContainer')?.classList.toggle('stickyContainer', isSticky)
    document.querySelector('.searchComponent')?.classList.toggle('stickySearchComponent', isSticky)
})

.stickySearchComponent {
    border-radius: 0;
    padding: 12px 46px;
    box-shadow: 0 0 10px 18px rgba(0, 0, 0, 0.3);
}
.searchContainer {
    position: sticky;
    top: 0;
    transition: 0.1s all ease-in-out;
}
.stickyContainer {
    max-width: 100%;
}

I also added different animation times for the search component and it's parent container. This will give that nice effect of bounciness.

PS. I had to add top: -1px in CSS instead of top: 0 in the CodePen above just because the IntersectionObserver events don't trigger there for some reason. You can safely use top: 0; in CSS in a normal browser.

Going deeper

Fixing the memory leak

In a real-world case, you may run into a memory leak issue if you use the example above. This is because we are not .unobserving() the element when our element is removed from the screen. It's not the case in the above example because we are not observing the element many times.

This issue is more common if you are using a frontend library or framework which destroys and re-renders the elements on the page many times. This will make the event handler run many times and add multiple observers on the target element.

You probably noticed this function returns an object with the observer and the element we are observing. We can use these to trigger the .unobserve() method, thereby freeing the memory and solving the memory leak:

const sticky = onSticky('.searchContainer', isSticky => {
    // "sticky" event handler
})

// use this to "unobserve" the element to free up the memory
sticky?.observer.unobserve(sticky.element)

Improving the DX (Developer Experience)

We can go even further and improve the DX of this function a bit by making it accept either a CSS selector string or an HTML Element instance as its first argument:

function onSticky(selector: string | HTMLElement, callback: (isSticky: boolean) => void) {
    const element = typeof selector === 'string' ? document.querySelector(selector) : selector

    if (!element) {
        return
    }

    const observer = new IntersectionObserver(
        ([event]) => callback(event.intersectionRatio < 1),
        {threshold: [1], rootMargin: '-1px 0px 0px 0px'}
    )
    observer.observe(element)

    return {observer, element}
}

We will explore how to implement a custom hook on React, Angular and Vue in upcoming articles.

That's it. Let me know if you have any thoughts on this.

Should I write an article about making this into an NPM package?
Should I go even deeper?

You can follow me on Twitter to see more content like this @ionelLupu_

How to display Weekday names in your User's language

Ionel Cristian Lupu — Wed, 31 May 2023 05:38:35 +0000

The other day I came across a tweet from @trunarla{:target="_blank"} about how can ternary operators can be made more readable:

Link to the tweet

I know the purpose of this piece of code is to promote ternary operators, but I couldn't help but notice we can refactor this specific code so we don't use ternary operators.

Refactor 1: Array of Weekdays

If we take a look at the code, we can clearly see we can have an array of weekday names and use the dayNumber as an index for that array:

const weekdays = ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday']

function getDayName(dayNumber: number) {
    return weekdays[dayNumber] || 'Invalid day number'
}

console.log(getDayName(2)) // Tuesday

Great, the code is already looking neater, don't you agree?

Refactor 2: Multilingual Support

In a real-world scenario, we will probably have to support multiple languages and our current implementation can't do that. Wouldn't it be nice if it could return the weekday name in the user's language.

My idea is to create an object where the keys are the language codes (called "locales"), and the values are the array of weekdays names in that language:

const weekdays: Record<string, string[]> = {
    'en-US': ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'],
    'fr-FR': ['Dimanche', 'Lundi', 'Mardi', 'Mercredi', 'Jeudi', 'Vendredi', 'Samedi'],
    // add more locales as needed...
}
function getDayName(locale: string, dayNumber: number) {
    return weekdays[locale][dayNumber] || 'Invalid day number'
}

console.log(getDayName('fr-FR', 2)) // Mardi

This change enables us to return the weekday name in different languages based on the user's locale. We can add more locales as needed.

Let's not hardcode the locale and get it directly from the user's browser using the navigator.language built-in helper.

const weekdays: Record<string, string[]> = {
    'en-US': ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'],
    'fr-FR': ['Dimanche', 'Lundi', 'Mardi', 'Mercredi', 'Jeudi', 'Vendredi', 'Samedi'],
    // add more locales as needed...
}
function getDayName(locale: string, dayNumber: number) {
    return weekdays[locale][dayNumber] || 'Invalid day number'
}

console.log(getDayName(navigator.language, 2)) // Tuesday (my browser is in English)

Refactor 3: Using the `Intl` object

You probably noticed this code will get massive if we want to support all the languages. This is where the built-in Intl object comes to the rescue. It provides a standard way to handle internationalization (fancy word for multiple languages) and enables developers to format and manipulate dates, numbers, and strings according to the user's locale.

We can scratch out our entire code and use this instead:

function getDayName(locale: string, date: Date) {
    return new Intl.DateTimeFormat(locale, { weekday: 'long' }).format(date)
}

console.log(getDayName(navigator.language, new Date('2023-05-23'))) // Monday

Much cleaner. I also replaced the dayNumber argument with a Date instance since in most cases this is what you will be using.

Exploring different day names formats

We can play with the weekday property of the DateTimeFormat function and see different way to display the weekday:

function getDayName(locale: string, date: Date) {
    return new Intl.DateTimeFormat(locale, { weekday: 'short' }).format(date)
}

console.log(getDayName(navigator.language, new Date('2023-05-23'))) // Mon

function getDayName(locale: string, date: Date) {
    return new Intl.DateTimeFormat(locale, { weekday: 'narrow' }).format(date)
}

console.log(getDayName(navigator.language, new Date('2023-05-23'))) // M

Imagine implementing all of this functionality in your project manually. It's a nightmare.

This final version of our function is much more powerful, flexible, and elegant.

That's it from my side. See you in the next one.

Twitter: Ionel Lupu
Webiste: https://ionel-lupu.com/

Typetron now has WebSockets

Ionel Cristian Lupu — Fri, 03 Dec 2021 20:16:52 +0000

Intro

Typetron aims to have one of the easiest and most intuitive developer experiences in a framework. That's why all of the Typetron's features merge seamlessly between each other offering your app a sense of belonging when you combine your business logic with the framework.

What's new

The last addition to the Typetron's toolbelt is the ability to create real-time, interactive applications using WebSockets in easy and simple way.

TLDR: Here is a repo with WebSockets examples using Typetron and different technologies: Angular, React, Vue or just a simple Webpack setup.

Configuring WebSockets

Typetron comes with the WebSocket server activated by default on port 8001. This setting is in the app/config.ts file:

import { AppConfig } from '@Typetron/Framework'
export default new AppConfig({
    // ...
    websocketsPort: 8001,
    // ...
})

If you want to remove the WebSocket feature from you app, just remove the port websocketsPort config line.

Once you start your Typetron app you will see a message in the command line saying that your WebSocket server started on that port:

Websocket server started on port 8001

Creating WebSockets events on the backend side

Now, you can start receiving and sending WebSocket messages from and to the server. All we have to do is to define what events our app will handle. You can add an event in any of your controllers by creating a method that has the @Event() decorator. Take a look at this example:

import { Controller, Event } from '@Typetron/Router'

@Controller()
export class MainController {

    @Event()
    welcome() {
        return 'Welcome to Websockets'
    }
}

Listening to WebSockets events - solution 1

Having this, we can now create a client that will send and receive WebSocket events. Typetron comes with a handy frontend package that will help you do just that. You can install it in your app (Angular, React, Vue, etc.) using this command:

$ npm install @typetron/websockets

After installing it, we can connect to our server and start sending and receiving events. Let's fire the welcome event and listen for a response back from the server:

import { Websocket } from '@typetron/websockets'

export const socket = new Websocket('ws://localhost:8001')

socket.on('welcome').subscribe(response => {
    console.log('Backend response', response)
})

socket.emit('welcome')

You should now see this message in the console:

Backend response Welcome to Websockets

Listening to WebSockets events - solution 2

If you don't want to use @typetron/websocket library in your frontend app, you can easily just connect to the WebSocket server using the built-in WebSocket API from Javascript but doing so, you will have to manually parse the Typetron WebSocket message on your frontend app. The format of the message is a simple JSON object that looks as follows:

// when sending a message
{
    "event": "event name",
    "message": { // optional
        "body": "content sent to the controllers",
        "parameters": ["param1","param1"] // controller method parameters (optional)
    }
}

// when receiving a message
{
    "event": "event name",
    "status": "OK" // or "Error",
    "message": "backend response" // optional
}

Having this in mind, let's connect to Typetron using the Javascript's built-in WebSocket API:

const socket = new WebSocket('ws://localhost:8001')

socket.onopen = () => {

    socket.onmessage = message => {
        const response = JSON.parse(message.data)
        console.log('Backend response', response.message )
    }

    socket.send(JSON.stringify({event: 'welcome'}))
}

Opening your frontend up should result in a console message similar to the one above:

Backend response Welcome to Websockets

Outro

And that's it. You can now build real-time apps using Typetron and WebSockets. Keep in mind that this feature is still in progress as many more functionalities will added.

Here is a repo with WebSockets examples using Typetron and different technologies: Angular, React, Vue or just a simple Webpack setup.

In the next articles in this "Typetron WebSockets" series we will build a "ToDo app" with Angular, React and Vue. Subscribe to the newsletter to be notified when we publish these articles.

Check the website typetron.org
Github repo
Let's talk on Discord
Typetron Twitter @Typetron_
My twitter @ionellupu_
Come and leave a question on Reddit
Join the Facebook group

Twitter clone app with Typetron

Ionel Cristian Lupu — Sat, 17 Apr 2021 08:29:40 +0000

Hello fellow devs!
Need your feedback.

Really excited to present an actual working app (hopefully 😄) made with Typetron: a Twitter clone app. Here are some screenshots:

Questions you may have:

1. What is Typetron?

Typetron is a batteries-included (not yet, but I will get it there) Node.js framework written in Typescript that allows you to create web apps, especially backend APIs.

2. Why did you build Typetron?

Building a framework was one of my side-projects created to learn how a web framework works and also, to learn Typescript. It was not my intention to create a competing framework 😅. After it was presented on a small local meetup, people there wanted to know more about it and therefore I created a website and added documentation. Then, after making some performance and developer-experience comparison with the other available frameworks, I decided Typetron is a good addition to the community and I continued working on it.

What do you think about it? Don't hesitate to leave a comment.

My Twitter - @ionelLupu_
Typetron Twitter - @Typetron_
Website - typetron.org

Typetron has a CLI now

Ionel Cristian Lupu — Tue, 06 Apr 2021 21:13:37 +0000

A few months ago I released the Beta version of Typetron and since then I've made a few changes to it and added some new features. One of it is the CLI.

The CLI was created to make dev's life easier by giving them a set of tools to automate some parts of the development process.

Installation

Installing Typetron's CLI is easy enough, as you would already expect:

$ npm install -g typetron

This will create a global command called, well, typetron.

This command line tool has a few sub-commands that you can use. Here is a list of them:

The new command

$ typetron new MyProject

As you are already used to in CLIs, the new command creates a new Typetron project with a basic scaffolding and installs its dependecies.

The routes command

$ typetron routes

Tis command will print out all the routes in your Typetron project together with some information about them. It comes in handy when you have a lot of them in a big project.

The migrate, migrate:rollback and migrate:reset commads

$ typetron migrate
Migrating...
Migrating 'CreateUsersTable'
Migrated 'CreateUsersTable'

$ typetron migrate:rollback
Rolling back...
Rolling back the 'CreateUsersTable' migration.
Reverted 'CreateUsersTable' migration.

$ typetron migrate:reset
Resetting database...

These commands are used to manage your Typetron app migrations

Check the website typetron.org
Typetron Twitter @Typetron_
My twitter @ionellupu_
Come and leave a question on Reddit
Join the Facebook group
Let's talk on Slack

Typetron Beta is here: typetron.org

Ionel Cristian Lupu — Wed, 10 Feb 2021 15:29:17 +0000

Since my last post about Typetron there have been some crazy months but it is finally here.

Typetron BETA is here!

Typetron is a Node.js web framework used for creating backend services. I demonstrate this in two of the available tutorials:

How does it look like in code?

Controlers

import { Controller, Delete, Get, Put, Post } from '@Typetron/Router'
import { Article } from 'App/Entities/Article'
import { ArticleForm } from 'App/Forms/ArticleForm'

@Controller('articles')
export class ArticleController {
    @Get()
    all() {
        return Article.get()
    }

    @Post()
    add(form: ArticleForm) {
        return Article.create(form)
    }

    @Put(':Article')
    update(article: Article, form: ArticleForm) {
        return article.fill(form).save()
    }

    @Delete(':Article')
    async delete(article: Article) {
        await article.delete()
    }
}

Entities

import { Column, Entity, ID, HasMany, Relation } from '@Typetron/Database'
import { Comment } from 'App/Entities/Comment'

export class Article extends Entity {
    @Column()
    id: ID

    @Column()
    title: string

    @Column()
    content: string

    @Column()
    createdAt: Date

    @Column()
    updatedAt: Date

    @Relation(() => Comment, 'article')
    comments: HasMany<Comment>
}

If you don't know anything about Javascript or Typetron, you can find some great FREE courses here that I recommend you to watch

It would be great to see your feedback and what features you would like to see in a framework like this. Take the tutorials and see what's missing 😄.

Check the website typetron.org
Twitter at @Typetron_
My Twitter @ionellupu_
Come and leave a question on Reddit
Join the Facebook group
Let's talk on Slack
Linkedin - Typetron

🚀 Typetron alpha is officially out: typetron.org

Ionel Cristian Lupu — Thu, 23 Apr 2020 14:56:46 +0000

I've been working on a Node.js framework for building REST APIs lately called Typetron and I wanted to announce it's alpha release together with its first tutorial where I show you how to build a simple backend for a personal blog. 🔥🔥🔥

I know, I know, another Javascript framework. Even tho' Typetron can't promise you now that is a great framework, I hope it will blow you away with the version 1.0 release (which I hope I can get out at the end of summer).

After this announcement, I will start working on its second tutorial that will mark the Beta release, where I will show you how you can make a DEV.to clone. I hope I can get the frontend tutorials ready also. Typetron will have support utilities to play seamlessly with your frontend app.

It would be great to see your feedback and what features you would like to see in a framework like this. Take the first tutorial and see what's missing 😄.

Check the website typetron.org
Twitter at @Typetron_
My Twitter @ionellupu_
Come and leave a question on Reddit
Join the Facebook group
Let's talk on Slack
Linkedin - Typetron

How I removed a ton of if statements from my Angular app

Ionel Cristian Lupu — Wed, 22 Apr 2020 14:33:43 +0000

Maybe you don't make the same mistakes like I do in Angular, but I wanted to share with you how I removed a lot of if statements from my code by simply using parameters in methods.

Let's imagine you have an UserComponent that shows the user's name and there is a button to delete it:

import { Component, OnInit } from '@angular/core';

interface User {
    id: number;
    name: string;
}

@Component({
    selector: 'app-user',
    template: `
        <p>Welcome {{user.name}}!</p>
        <button (click)="removeUser()">Remove user</button>
    `
})
export class UserComponent implements OnInit {

    user?: User;

    async ngOnInit() {
        this.user = await fetchUser(1);
    }

    async removeUser() {
        if (this.user) { // this is what we will remove later
            await removeUser(this.user.id);
        }
    }
}

This works fine (assuming we've implemented the fethUser and removeUser functions) even if we build for prod with ng build --prod.

But when working with Typescript, you will hear everyone saying to enable strict mode to protect developers against common errors. You can do it inside the tsconfig.json file:

{
    "compilerOptions": {
        "strict": true
    }
}

The app still works, but if we are trying to build for production now, we will get the following error:

ERROR in src/app/user/user.component.ts.UserComponent.html(2,12): Object is possibly 'undefined'.

This is because Angular is trying to protect us against undefined values by checking our templates. In this case, the user variable has the type User|undefined. This is fine. We can fix this by using a condition in the template:

    <ng-container *ngIf="user">
        <p>Welcome {{user.name}}!</p>
        <button (click)="removeUser()">Remove user</button>
    </ng-container>

This will fix all the errors, but we have two if conditions in our app and we are trying to get rid of most of them.

Type checking in templates work the same as in typescript: types are narrowed if a condition is used. This means that the user variable inside the ng-container will only have the type User because the undefined type was stripped by the *ngIf directive.

This means we can now pass the user as a parameter to the removeUser method and remove the if from there. This is the final component:

import { Component, OnInit } from '@angular/core';

interface User {
    id: number;
    name: string;
}

@Component({
    selector: 'app-user',
    template: `
        <ng-container *ngIf="user">
            <p>Welcome {{user.name}}!</p>
            <button (click)="removeUser(user)">Remove user</button>
        </ng-container>
    `
})
export class UserComponent implements OnInit {

    user?: User;

    async ngOnInit() {
        this.user = await fetchUser(1);
    }

    async removeUser(user: User) {
        await removeUser(user.id);
    }
}

Do you have any other sweet tips like this one? Share them in comments! 😁

Follow me on Twitter for more awesome stuff like this.
Check Typetron, the Node.js framework I am working on.

Problem: Calling static methods of target's parent when using a Javascript Proxy object

Ionel Cristian Lupu — Sat, 07 Sep 2019 09:07:59 +0000

Sep 7 '19 Comments: 1 Answers: 1

Really interesting problem here for Javascripters

In Javascript, is possible to intercept when getting a property using proxies.

Also, with a small hack as shown below, is possible to intercept when getting a static property of a class:

class Handler{
    constructor(object){
        this.object = object;
    }

    get(target, property){
        if

…

Open Full Question

DEV Community: Ionel Cristian Lupu

IP to Country Detection with GeoPulse.pro

Getting Started

Step 1: Sign Up and Get Your API Key

Step 2: Download the GeoPulse server

Async/Await Traps: The importance of await in try/catch blocks

'onSticky' Event hook in React

Going from vanilla to React

Going deeper

Fixing the memory leak

Creating the custom hook

Using refs instead of class names

Going even deeper

Conclusion

Crafting an 'onSticky' Event Handler

The code

The explanation

Adding animations

Going deeper

Fixing the memory leak

Improving the DX (Developer Experience)

How to display Weekday names in your User's language

Refactor 1: Array of Weekdays

Refactor 2: Multilingual Support

Refactor 3: Using the Intl object

Exploring different day names formats

Typetron now has WebSockets

Intro

What's new

Configuring WebSockets

Creating WebSockets events on the backend side

Listening to WebSockets events - solution 1

Listening to WebSockets events - solution 2

Outro

Twitter clone app with Typetron

1. What is Typetron?

2. Why did you build Typetron?

Typetron has a CLI now

Installation

Typetron Beta is here: typetron.org

How does it look like in code?

Controlers

Entities

🚀 Typetron alpha is officially out: typetron.org

How I removed a ton of if statements from my Angular app

Problem: Calling static methods of target's parent when using a Javascript Proxy object

Refactor 3: Using the `Intl` object