DEV Community: Olivier Guimbal

Introducing ngx-react : 🅰️Angular + ⚛️React interoperability without pain.

Olivier Guimbal — Tue, 28 Sep 2021 13:16:45 +0000

Have you ever wanted to use React components in an Angular application ? Or to start migrating an Angular app to React component-by-component ? Or simply use both at the same time ?

I developped ngx-react which allows you to do just that with ease.

It enables you to use your Angular components in React, and vice versa, quite transparently, and without boilerplate.

📐 Setup

Just declare a bridge, somewhere in your application:

import { NgxReactBridge } from 'ngx-react';

export const bridge = new NgxReactBridge()
    // bridge options:
    .addProvider(/** Add a global react provider here */);

Use 🅰️ in ⚛️

Then, to use an Angular component in React, just import it like that:

const AsReact = bridge.toReact(MyAngularCommonent);

// use it 👉  <AsReact prop={whatever} />

The generated ⚛️ component will take as props all the @Input()s of your 🅰️ component, and all the @Output()s, mapped to functions. (i.e. @Output() onThing: EventEmitter<string> will be mapped to prop onThing: (event: string) => void.

Use ⚛️ in 🅰️

To use a React component in Angular, you'll have to do a tiny bit more work... for instance if you have a React component:

function MyReactComponent(props: {
  data: string;
  dataChange: (evt: string) => void;
}) {
    // [...]
}

Then magically convert it to its Angular counterpart like that:

@Directive({ selector: "my-react-component" })
export class MyReactComponent_Angular extends reactBridge.toAngular(
  MyReactComponent
) {

  // a bit of extra work: You will have to map the properties yourself 
  @Input()
  data!: string;
  @Output()
  dataChange = new EventEmitter();
}

(the Angular compiler doesnt allow to build dynamic components... so we have to declare them statically)

Services

Just inject Angular services in React like that:

const service = useService(MyAngularService);

Wrapping up

I'll write more about this when I have more time 👉 But please share your thought if you have some :)

More details on the ngx-react repository

Learn functional programing with me - Part 1 : Language choice

Olivier Guimbal — Tue, 23 Feb 2021 07:56:58 +0000

So, I've decided to write a blog.

Sure, I could use one of many solutions out there and setup a blog in minutes, but writing a blog is not the main purpose here (who gives a 💩 about my opinion anyway ?).
I'd like to learn a language AND build something while doing so.

If you're interested, I'd like this to be collaborative in some way: You could comment my choices, learn from them, and influence them (for instance, you can today influence the language I will use - see below).

🤔 Why would you care ?

TLDR : I will explain, step by step, how I built it, and I will post all the resources that I used to learn how to do it along the way.

In my (relatively) long experience, I learnt and used on real projects many languages that could be qualified as imperative more than functional languages, such as Javascript/Typescript, C#, Dart, Java, VB, C++ (non exhaustive list).

I've always been toying with FP languages, but never had the oportunity to use them on an actual project, so I've decided to build a blog using one of those.

If like me, you already know imperative languages, but you're interested by learning a functional language, you might want to stick with this series.

It aims experienced developpers with at least a little bit of awareness about FP concepts.

Being myself a semi-begginer in most FP languages, you will probably learn the language progressively with me, see (and discuss?) my architectual choices, my mistakes, my misunderstandings, and the solutions I came up with.

🤪 Why do I do that ?

My goal here is to write a tutorial which is progressive, and hands on.

I'm tired of reading hundreds of attempts of guys who already got it to teach category theory by the menu, because they think that their approach at teaching it is better. Reading those, I've been admitedly learning a lot, but I feel incapable of building an actual project with all that knowledge. Which seems retrospectively crazy to me... I don't recall having this kind of feeling when learning simple non FP languages.

When it comes to learning, I believe practice is better that theory to begin with, and that learning practice with someone is better that learning it from someone. Even if it means not learning things the academic way.

🎯 Specifications - what should it do ?

Here is what I'm expecting it to do:

To be server-side rendered (for SEO) - so no client-only/SPA stuff.
To be serverless, and to be served via a CDN, zero fixed cost (if possible via Cloudflare Workers, because I 💖 them.. if not, via some kind of Lambda@Edge or equivalent, or even some kind of FAAS + github pages... why not ?)
To have a git repository containing .md files as raw source (I don't want any online editor, authentication system, or other 💩) - will probably be implemented using hooks/github actions which will update the actual blog.
To have multiple blogging categories (tech, opinions, ...), presented as columns on the landing page.
To support multiple formats: tweet-like, pictures, videos, articles (to begin with)
To automatically repost articles I'm writing on various medium (dev.to, medium.com, reddit, twitter, mastodon, ...), and if legally and technically possible, show the associated comments/likes/claps/retweets/etc on the main blog.
To be written using FP language(s)

👅 Language

So, I must say, I've toyed a lot with FP languages, thinking that at one point, one of those might strike me as "the best for my needs". That did not happen. Instead, I got lost along the way, learning a little bit about each one, but never mastering any.

Here is a non exhaustive list of the languages that I considered:

1️⃣ Purescript
2️⃣ ELM
3️⃣ ReasonML/ReScript
4️⃣ Haskell
5️⃣ Clojure(Script)

Below is my perception about each one of those.

As of writing this article, my curiosity about Haskell or equivalent would make me choose Purescript (I'm not settled on the UI lib to use).

If you'd rather see me write it in another of those languages, please comment, I might (or might not) be convinced or influenced , and take your choice into account 😊

1️⃣ Purescript

Purescript is a child of Haskell (their syntax are almost identical), targeting mostly Javascript.

✔ PROS:

Pure FP Purescript is a pure functional language. This seems to bring a lot of liberties and guarantees while reasoning about your code.
Interop: It outputs quite readable Javascript, and has a very clean FFI (meaning that you can interact with existing Js code/libraries very easily).
Client+Server:It is usage agnostic, meaning that it can be used both server-side (running NodeJS), and client-side
Typing: I've only explored a bit of them, but Haskell-like type systems seems soo smooth, and leads to elegant implementations.

💥 CONS:

Learning curve: This is no little thing, it is a "next-level" programming language. Meaning that the concepts that you can play with are so much more powerful and advanced that your brain will hurt by learning it. A single line of code can hide much more meaning compared to a classic language, which always make you wonder if you got it all, when reading code. Seems to worth it, though.

📚 Framework:

My first exploratory work would point at either purescript-halogen or purescript-elmish.

Halogen seems nice and widely used, but its SSR story is less clear. On the other hand, Elmish has the advantage of kind-of learning Elm along the way, but is less used (then, there will be less learning resource).

2️⃣ ELM

Like Purescript, Elm is also a child of Haskell, but much more simpler. It actually feels like a simplification + specialization of Haskell, bringing more guarantees on the table, along with a much more nicer syntax error messages.

✔ PROS:

Pure FP ELM is also a pure functional language.
Safety: ELM proudly guarantees near-zero runtime exceptions. Meaning that it is literally impossible to encounter any runtime error with ELM (except inevitable things such as out-of-memory & stack-overflow errors). It obviously does not imply that you cannot write errors in your logic, but it means that if it compiles, it will not crash.
Error messages: ELM is very well known to have state-of-the art syntax error messages. They seem useful, pointing at solutions/suggestions/useful links.
Bundle sizes ELM seems to crush every other language/framework when it comes to bundle size. ELM bundles seems to casually weight about an order of magnitude less than other tech typical bundle sizes.
Relatively widespread: Compared to the other languages I considered, I think ELM is the most used to build frontends (it still remains a fringe comunity, though)
Relatively easy to learn Its ecosystem is very simple... there is often only one way of doing things, and its syntax is straightforward... that makes it easy to learn.
Coherent ecosystem The community around ELM seems helpful, not flawed by the dissentions I seem to have percieved in other communities, and its package system is rock solid (it enforces semver to published libraries, ensuring nothing will ever break)

💥 CONS:

No SSR - That is not a small one... ELM cannot do SSR + Hydration. Meaning that we will have to choose between server side rendering and interactivity. I think I would have chosen ELM no question asked if it did suport SSR. But I'm not trying to build a SPA :(
Interop - As neat as the dev experience is using ELM, it is quite bad when it comes with interacting with JS. You have to communicate through ports, which are quite rigid and tedious. You'll also have much trouble on basic things when it comes to speaking non-elmish, like when deserializing JSON coming from an AJAX query (If i'm correct, you'll systematically have to implement explicit ad-hoc JSON decoders 😑).

📚 Framework:

Not relevant :) ELM is its own framework !

That said, elm-ui seems quite interesting as a library. I think I would use it

3️⃣ ReasonML/ReScript

It is an OCaml descendent.
It seems to put an accent on interoperability with JS, and pragmatism. But I don't know much about it except the basic syntax.

So any feedback is welcome.

✔ PROS:

More familiar: While you could not guess what random code from the previous two languages is doing without any initiation to their syntax, Reason feels more familiar. It "looks like" something you would understand if you already know languages which are not considered as purely functional, but have some affinity with the functional style, such as Scala, Rust, Kotlin... and even JS.

💥 CONS:

Messy ecosystem: Sooo... well... It takes at least half an hour to understand that Reason, ReasonML, ReScript, Bucklescript, and all that are actually kind of the same thing, I guess, but not really, but they're not anymore, but they are transitioning, but ... wait wat ? Couldnt someone tell me why all the fuss ? Couldnt we have one way to go ? And how am I sure I'm not starting to use a version that will lead me to a dead-end ?

📚 Framework:

Like I said, I don't know enough about it, but reasonreact seems to be the way to go ! Any feedback appreciated

4️⃣ Haskell

The father of all languages. Over the decades, Haskell has never exploded in popuplarity, but it has inspired in one way or another most of the typed languages out there.

✔ PROS:

Syntax & type system: Same as purescript... Haskell feels and is very powerful.
Performance: Not really something that is useful when chosing a language to write a blog, but Haskell can compare to C++ in terms of performance.

💥 CONS:

Server only: There is no efficient way to use Haskell client-side. Weirdly enought, we'll face the same dilemma as with ELM (which is client-only).
Learning curve: Same as purescripts...
Somehow weird ecosystem: I wrote about it here, but Haskell has been out there for a very long time... meaning that you never know when a resource is relevant, abandoned, ...

📚 Framework:

Given that Haskell is only running server-side, and given the "serverless" constraint, using Haskell with widespread frameworks to develop websites such as yesod seems out of the question. If using Haskell, I would have to write some kind of lambda which generates a fully static website. After a bit of research, it would seem that an aws lambda running aws-lambda-haskell-runtime should be a good match.

5️⃣ Clojure(Script)

Clojure (or Clojurescript if you want to compile to JS) is a Lisp language.

I included it here because I used to play a bit with Clojurescript a while ago, and I found it quite original, but I wont dive into details here, since I find it too diferent to be compared with the other 4:

Is is a fully dynamic language, no typing (there is spec, though)
Like all Lisps, it does not have a syntax, per se. It's only parenthesis 🤪
Is is quite flexible

... but I have not investigated weather if SSR is easy, nor about its deployability on a FAAS platform (that said, it runs on the JVM, so it should be the same as Java), cold-start times, etc... and I'd prefer using a typed language. So I'd need a lot of convincing to go with that one ! (even if I like it to play, learn, and write prototypes)

👋 Conclusion

Okay, that was long. So I have questions:

What do you think ?
Would you have something to add or to correct ?
Would you be interested in following such a series ?
Which language interests you the most ?
Have I forgotten a FP language that you love and would like to be considered ?
Which kind of supporting tech (lambda, cloudflare workers, azure functions, github actions, ...) ?

If this interests some, I will post articles & thoughts as I develop this blog. Otherwise, well... I guess that will remain a private journey !

Thanks for reading, and stay tuned for the follow-up !

Haskell as a first timer - Am I missing something ?

Olivier Guimbal — Wed, 03 Feb 2021 08:59:50 +0000

NB: This is also commented on reddit

So... I've been toying a lot with Haskell lately.

But I feel a bit schizophrenic about my first impressions. There
is something both very right, and very wrong about it.

While addressing most of my top concerns about other languages, and giving me hope to discover a language that I could love, the Haskell ecosystem seems in the meantime broken where I expected it the least to be. It is sooo frustrating, and leaves a bitter taste of unachievement :(

Have I missed a crucial step ? Or is there really something broken in its ecosystem ? (may it be a victim of its age × lack of wide adoption ?)

Let me elaborate a bit.

💖 First looks - The (very) good parts

I wont dive into details, since this is widely documented, but in short, I loved:

Its world-class type system 😱 so smooth.
Immutablility, Pure FP, all that good stuff.
Its syntax. Not the most beginner friendly, but if feels smart and concise when you get it. Other languages then tend to feel verbose.
That it looks like maths
The simplifications the compiler hints at
The depth of this language. I only got a glimpse of its abstraction power, and it is definitely not playing in the same league as others. It is so exciting not to feel that a compiler is forcing you to write dumb things just because language designers felt like "this" or "that" abstraction was not part of the language.
TDD as in Type-Driven-Development 😁 If you've ever searched for a type signature on Hoogle, you'll get what I mean.
Great learning resources such as learn you a haskell or fp complete

You get the picture, I think that Haskell in itself is neat. But seriously, WTF is wrong with its ecosystem ?
Once you're done toying, and start to get like "okay, now lets do real world shit", everything seems to fall apart.

🥪 Frustration 1 - Stack configuration

If I understood right, stack was supposed to bring to Haskell a decent all-inclusive CLI equivalent to those that you have with Dotnet, Deno, Elm, and whatnot.
Okay. It kind of seems to be (or at least a huge improvement over not having it).

But when npm and friends set a standard of having one file which defines your package (dependencies, and such), why deviate from it introducing package.yaml and stack.yaml ? How the f*** am I supposed to guess that I must read a random part of the Stack documentation to understand that yea, you can install packages by adding them in package.yaml, but for some of them, you must also add them in stack.yaml ... wait ... what ??! Okay, it makes kinda sense once you know why, but why not stick to the "expected" way to go by default ?

When learning a new language or framework, I usually spend minutes trying to understand how the associated CLI & package manager works. I had to spend frustrating hours on stack to understand that it just dont work as others do. What's even more confusing is that it almost does ! Why not ? And why not a "stack install xxx" command which writes yaml files ?

💥 Frustration 2 - Stack error messages

Is it just me ? Or does installing a library though stack is just like playing russian roulette ?

I think everyone who's been a solo Haskell learner might at one point or another felt that sentiment of hoplessness, despair, and self doubt when Haskell tooling just keeps throwing at you thousands of giberrish error lines for no appearant reason, just because you tried to install a package or such (especially if you're already mastering several other ecosystems which behave "as you would expect")

For instance, how the hell am I supposed to make sense of this kind of error logs without getting a headache reading usless stuff ? (for the record, I just added a very widely used package to package.yaml... nothing fancy !)

I would expect Stack not to tell me "please scroll up an unkown number of lines to find the error yourself". Especially since there are a lot of things that look like errors between me and the actual error. I guess one can get used to it, but if the point of a nice build tool isnt to help you, what is ?
I would expect the luxry of a colorized console output, somehow ?
The actual error does not even mention the word "error" 😩 Pretty hard to find the error by yourself when you dont know what you're looking for.
If a native dependency is required, isnt it the toolchains' job to abstract that away, and to install it, or at least tell me how to install it (hint: for my error, I guess that a 600MB apt-get install pg is not the answer)

Most of the significant libraries I tried just failed miserably to install for one reason or another. Which leads me to my second frustration.

🤼 Frustration 3 - Maintainers ?

Is it just me ? Or most packages are just abandonned, even sometimes left in a state that is no longer compatible with newer versions of the GHC, with nobody left to answer 3 years old issues and pull requests ?

I am definitely okay (even a bit excited by) trying to adhere to a fringe ecosystem. I dont need millions of downloads to feel safe about a piece of code I'm using. But I fear dead communities, and it has been a bit puzzling to see how inactive most of the repos I encountered are...

Dont get me wrong: I am trying to contribute to opensource as well, so I get that supporting small projects can be demanding. There's nothing wrong in not spending your weekends on OS. But not asking for help, nor specifying that a project is unmaintained, nor even answering issues & pull requests for years feels just wrong.

nb: I dont think too much finger pointing will solve anything, so I wont name any specific library, but you dont have to search very long to find such libs on hackage.

📚 Frustration 4 - Documentawhat ?

I wont moann too much about it because I'm definitely not the first one to point that out.

I get that the holly Types are enough. I get that. But I could argue that even if you could theorically learn gibberish by reading a dictionary on a smartwatch, its usually more pleasant to read, watch or listen to actual people, producing actual sentences.

I dont understand. When you're willing to sacrifice your time to opensource... Why not writing 10 lines targetting mere mortals willing to use your code to tell the general idea behind your work ? Not doing so just feels a bit like "go fuck yourself & read the types, you dumb monkeys" 😯

👉 Conclusion - Please enlighten me

That's where I stand. I am very excited by Haskell, while really puzzled to find myself not willing to try to write actual production stuff with it, for absurd reasons.

These are just small glitches, in the sense that they feel just like superficial flaws, which have been overcome in almost all decent language communities... but they are crippling enough to me so I dont see how I could not have problems working with Haskell.

Still, I will continue to fiddle around with this awesome language, but I gave up my short term plans to build something real with it.

But I'm very open to someone willing to change my mind... What do you think ? Is Haskell dying, or in a status quo, being okay mid distance from a research language to a widely adoptable & production ready thing ? Or is it still a passionate community it seems to have been ? Are those flaws a temporary thing, or the symptoms of something rotten ? Have you had recent production successes with Haskell ? What's your reciepe to onboard people ? How do you see the future for Haskell ? What do you think of Purescript ?

ps: Sorry if my English is off, I'm french :)

My favorite pages on the whole internet

Olivier Guimbal — Sat, 28 Nov 2020 15:16:41 +0000

I know it has little value to just dump links like that, but those have made me laugh so hard each time I visited them that I feel compeled to share them, in case you dont know them !

WAT ? talk is by far my favorite. I Listened to it millions of times. Still funny.
Learn why unit testing is important
Get some inspiration here for your comments.
Have a wise advice before deploying in production
Be aware that correlation does not imply causation
I sometimes find myself not liking XKCD... then I remember these
Some less funny links but still worth a click

Dont hesitate to share yours !

(and check out the lib I recently published if you have some time to spare !)

localStorage vs cookies: the "tabs vs spaces" sterile debate of web development 🙄

Olivier Guimbal — Wed, 25 Nov 2020 09:32:24 +0000

EDIT: The title not being clear enough (I thought it was implicit): This article is about the "storing tokens in localStorage or in cookies for SPAs" debate. It is NOT about using cookies to store general purpose data.

I'm a tad tired of reading "dont use localStorage, it's not secure". Why ? Oh, yes "its accessible in JS". Let me tell you how this seems to be an overrated argument to me.

If someone owns you, someone owns you.

If someone can run arbitrary JS on your website, do you really believe a peremptible JWT will necessarily be the only thing that can be exploitable ?

Personally, I'd go with something far more interesting to me: Collecting what user are typing in password boxes. Or just performing the requests that interest me directly from their browser. Those exploits are even easier to write when using cookies, given that you dont have to guess where is the token stored nor how to use it.

Cookies also have their drawbacks

Protecting against CSRF is not that easy, and beginners are not even aware of it.
Implementation of multiple authentication is harder (if you're writing a signle API that must be usable in multiple websites)
You cant control them (easily tell if you're logged-in, read associated data, ...)
CORS is harder with them.
etc...

XSS / Malicious JS dependencies: The easy fix.

You're worried that one of your dependencies might be accessing your localStorage maliciously ?

Well, that's not a strong valid argument, you could just prevent it to do so like that when bootstraping your application:

const storage = localStorage;
delete localStorage;

And voilà ! There is no more localStorage exposed in your window, but you still can access your tokens via the "storage" local variable (of course, you must keep it in a private scope).

These two lines of code will protect you from the most obvious and common exploit that localStorage is blamed for.

(of course you could imagine spying tokens by overriding fetch or equivalent, but that also is mitigable... its about preventing 99% of exploits, this is not strong security)

If other parts of your app need to access local storage, you could set window.localStorage to a proxy that only lets the user access non critical parts of your local storage, leaving your precious tokens out of their sight.

Which one to use then ?

I think that the web has more suffered (and is still suffering) from CSRF attacks compared to stolen JWTs, so dont tell me that https cookies are the secure way to go. Unless you're writing ultra-secure and highly-reviewed code, no, they're not. Its easier to make mistakes with cookies compared with localStorage tokens.

Just to be clear: I dont prefer one over another... I'm just saying that this debate is a bit useless, both approaches having their own sweetspots and weakspots.

I'm just sick of people explaining you otherwise with a condescending tone just because they think they've understood all there is to know by saying "its accessible by JS". Or because they've read somewhere that localStorage tokens might be considered as a potential security leak by some. Give me a break. The world is about nuance, not about dogmas.

Happy to hear what you think of this in the comments.

Zero delay development & unit testing iterations

Olivier Guimbal — Tue, 06 Oct 2020 06:51:23 +0000

If you write js or ts targeting node, and would like to improve your daily life and your productivity, yey 🎉 this article is for you !

TLDR

As devs, our daily life is often a constant back and forth between:

Writing code
Running unit tests
Running the written code "for real"

You may have noticed how joyful it is when this iteration process is fast enough so you can have this instant feedback loop between writing and testing.

This article explains how to leverage Webpack HMR in order to get instant restart/reload/run for your NodeJS server and your Mocha unit tests, whatever your codebase size.

To get a glimpse of what I'm talking about, you can clone this repo and follow "Development" instructions (by the way this is a small OS lib I maintain, I wrote about it here)

What is HMR, and how can it be useful ?

If your project is big enough, you probably experience painful delays... when you save a line of code, It might takes ages (or at least seconds) to:

reload your unit tests and/or rerun them
restart your localhost server in order to test this line of code.

That is because in either case, your whole codebase must be reinterpreted by node (and possibly retranspiled if you use Typescript with ts-node), including all your node_module dependencies. That is A LOT of code to reparse and reexecute for a single line of code changed.

That is where HMR (Hot-Module-Reload) come in handy.
I wont go into the details of it (Google is your friend), but in two words, the idea is to keep your server running, and only reload the modules that have changed when you save a code file. No need to restart your localhost sever anymore when writing simple changes.

Neat. How do I setup HMR ?

Webpack is a good way to do this.
It is often seen as a client-side devtool to bundle webapps, but It can also be used to bundle nodejs apps.

In short, you'll have to setup webpack for your nodejs server, enabling HMR. To do this, I can point you at this sample repo. It demonstrates how to setup a simple Typescript+Express server with Webpack HMR + unit testing (read its instructions before cloning).

Here is what happens when you change a line of code when changing your server code:

It just reloaded the changed file (main.ts), but all its dependencies are already in-memory. If you have hundreds of dependencies, and thousands of code files, your new server will be up and running again waaaay faster using this method.

To understand the black magic behind it, check:

webpack.config.js
The end of main.ts
.vscode/launch.json
The Webpack documentation about HMR

Although it is not that complicated, be aware of the fact that HMR is not pure magic. Try to understand how it works behind the hood, and you'll undersand its constraints (which are mainly due to the fact that the modules that are not reloaded may have static in-memory state which will be persisted between HMR recompilations).

Also make my unit tests fast again, please

If you are serious about developing NodeJS projects (or any kind of project for that matter), you probably write unit tests.

If you use vscode as an IDE, and Mocha as your unit test framework, you may already use mocha test explorer + mocha

In that case, you're lucky 🎉 It so happens that I forked the official mocha test adapter to bring HMR support to your unit tests.

We've been using it for a year in my company, it works quite well, and it is stable - do not hesitate to write an issue here if you have any trouble.
It brung the delay between hitting the ▶ button of a unit test and actually hitting a 🔴 breakpoint from 20 seconds to 0.5 sec 🤯.

Here is how it feels to run a thousand unit tests with it:

Or to debug one:

... And the good news is: It is that fast even if your codebase has millions of lines of code, thousands of dependencies, and you wont experience any delay when changing a line of code ❤

To set it up

If you carefully read the aforementioned sample repository, you might have noticed that it also defines an HMR ready unit testing configuration.

In short, it involves:

Creating a simple unit test entry point file that will reference all your unit test files (using context.require)
Creating a webpack bundle which uses this entry file
Telling mocha-test-adapter to use the bulit bundle as an HMR bundle via .vscode/config.js
Running the webpack bundler (npm start), then reloading all your tests

Read the instructions of this repo, it should work out of the box !

A tip to yet improve your iteration loop experience

Running a test should now be pretty fast.
However, you still have to click on 🐜 button, then ▶ each time you want to run a test. Which I found to be quite a hassle.

To solve this, in the spirit of my previous article

How to never touch your mouse again 🐭

Olivier Guimbal ・ Aug 18 '20 ・ 3 min read

#productivity #vscode

I recommend using the commands test-explorer.rerun, test-explorer.reload, test-explorer.redebug and test-explorer.run-this-test.

Here is my key bindings for those:

    {
        "key": "ctrl+f5",
        "command": "test-explorer.rerun"
    },
    {
        "key": "ctrl+shift+f5",
        "command": "test-explorer.reload"
    },
    {
        "key": "ctrl+alt+f5",
        "command": "test-explorer.redebug"
    },
    {
        "key": "alt+shift+f5",
        "command": "test-explorer.run-this-test"
    },

How to never touch your mouse again 🐭

Olivier Guimbal — Tue, 18 Aug 2020 08:12:42 +0000

VIM ? Well... no thanks.

You may already have met one of those extremists which have explained to you how productive VIM is compared to newbie editors like vscode or other modern useless shit.

To me, this always have sounded like some sort of hell-yea-i-am-a-real-geek nonsense. In perticular, they often hightlight the fact that VIM is highlly customizable. Weeeelll, yes. That's right. Or at least that was right: vscode (or other modern alternatives), is also highly customizable, in a way more user friendly fashion.

However, if like me you have been writing code for decade(s), you might have noticed (or not?) that one of the things that break your flow is to constantly switch between keyboard, arrow keys, and/or your mouse. When you have a burst, you may feel like hell-yea-my-hands-are-flying, but in the end, you spend a lot of time not typing actual code. That is one of the arguments of VIM-extremists, and I must say, this is the one that seduced me the most.

What if I dont wanna spend 32752 hours learning/configuring VIM ?

I'll share with you the two ways I achieved that.

Configuring vscode alone

Vscode shortcuts customization is awesome. You can do almost anything with it.

Here is a link to my key bindings, so you can pick what's best for you (⚠ my keyboard is AZERTY).

A config like this one allows you to navigate your code without moving your hands even slightly:

use ALT+I/J/K/L/U/O/Y/H/M/ù to move around
same shortcuts with SHIFT pressed to select code
use ALT+Q/S/D/Z to switch between panes
use ALT+SHIFT+Q/S/D/Z to move code panes around
use ALT+,/; to switch between tabs
... it also contains some other useful stuff check it out.

It takes several hours to get used to not touching your mouse, but there is no going back: It really worthes it.

However, when you configure this kind of shortcuts, it can feel a bit frustrating to edit text elsewhere "the old way" (notepad, word, or even in your browser).

That is the why of this next section:

System-wide configuration using AuthoHotKey (Windows only, sorry)

If you dont know autohotkey, it is a small software that allows you to write scripts that you can bind to keyboard shortcuts. It has a quite ugly syntax, but it makes it really easy to remap keys and interact with windows.

This autohotkey script will allow you to have almost the same experience moving around text as briefly described in the previous section, but system-wide.

(nb: It also contains a remapping of the F1 key that hides/shows Windows Terminal)

Other utilities

Jumpy

Moving around code using keyboard is nice, but you may feel like it is frustrating not to jump directly at a precise location visible on your screen (you'll want to click on this location).

For this, I highly recomend the jumpy vscode extension, which does just that using your keybard.

Switcheroo (Windows only)

ALT+Tab is quite frustrating... try switcheroo: Press ALT+Enter, then just type the window name you want to jump to 🎉

For those who want VIM bindings:

There are several extensions that will turn your vscode experience in something like VIM. Read this article to know more about it.

[edit] Vimium

If you want to control your browser mouseless, give a try to Vimium (or here for Firefox).

It has plenty of shortcuts allowing you to browse pages, navigate bookmarks, open tabs or click links using your keyboard

i18n - Express/Apollo GraphQL server translation made simple

Olivier Guimbal — Tue, 04 Aug 2020 16:02:05 +0000

The problem
The smarloc approach
Express.js: How to setup ?
Apollo GraphQL: How to setup ?
Generating translations
Wrapping up

Say you have a server.
Say you are using Express.js and/or Apollo Graphql server.
Say your users speak different languages.
Say you live in 2020, your server is only an api server, and dont care about templating engines.

🎉 Yey ! This article is for you.

It introduces yet another i18n lib I developped for my company needs which (IMO) simplifies the creation of multi-languages servers implementation.

The problem

When writing code in an Express route handler, you have access to the original "request" object.

"good" you would say. I can access "Cookies", "Accept-Languages" header, or whatever that defines my user language, and translate the returned content based on that.

To which I would reply: Okay sure, but do you really want to carry around your request object as an argument of some kind in your whole codebase, just for the sake of knowing your user language ?

Doesnt it feel kinda wrong ?

Arent you tired of calling weird static methods with weird syntaxes to get a translated string from your code ?

Are you really gonna refactor those 500k uni-language code files that you already wrote just to add language support ?

How the heck are you supposed to store translatable strings ?

If like me, you feel this is wrong, read on...

The smarloc approach.

A good example is worth a thousand words:

// before
const myFunction = () => `Hello, it is now ${new Date()}`;
// after
const myFunction = () => loc`Hello, it is now ${new Date()}`;

See the difference ? Yea, there is 'loc' in front of my string.
Your function is not returning a 'string' anymore, rather a 'LocStr' object.

Here lies the hack... you dont have to know your user language when you emit the string that will eventually have to be translated. You can pass around this object in your whole app without telling the code that manipulates it that this not an actual string.

Translation will then occur at the latest instant, when serializing the json response sent to your client. That's when 'Accept-Language' header or whatever will be read, and when instances of 'LocStr' strings in the returned json will really be translated. At the latest moment.

Express.js: How to setup ?

First and foremost (this must be done before any code uses smartloc), you'll have to tell which in which language you write you strings in.

import {setDefaultlocale} from 'smartloc';

// lets say our developpers use english in code
setDefaultLocale('en');

Then, you'll add an Express.js middleware which will translate returned json on-the-fly.

import translator from 'smartloc/express';

app.use(translator());

By default, it will look for translations matching the 'Accept-Language' header of incoming requests, and will default to the default language you provided.

You can now use smartloc like this

import {loc} from 'smartloc';

app.get('/', (req, res) => {
    // sends a JSON object containing text to translate,
    // without bothering to translate it.
    res.json({
        // this string will get an automatic ID
        hello: loc`Hello !`,

        // notice that you can provide an ID like that
        // and use regular templating syntax:
        time: loc('myTime')`It is ${new Date()}, mate !`,
    });
});

If you run this, you'll notice that your api will return things like:

{
    "hello": "Hello !",
    "time": "It is <put your date here>, mate !"
}

Okay, that's fine, but how that doesnt tell us how to provide actual translations to strings...

Yes, for that, you'll have to jump to the Generate translations section 🙂

A simple version of this example is here (nb: it provides hard-coded translations, not using translation files)

Apollo GraphQL: How to setup ?

Setting up for an Apollo GraphQL server is almost the same thing as setting up for an Express.js server.

In short, it is the same as described in the previous section, except you will not have to use the express translator middleware.

Instead, you will have to declare in your schema which strings are translatable by using the 'GLocString' type instead of 'GraphQLString', like this:

import {GLocString} from 'smartloc/graphql';

//...
{
   type: GLocString,
   resolve: () => loc`Hello !` // will be translated
}

Then build your apollo server like that:

import {localizeSchema, localizedContext} from 'smartloc/graphql';

const apollo = new ApolloServer({
    schema: localizeSchema(schema),
    context: localizedContext(async http => {
        // build your own context here as usual
        return {};
    })
});

When doing that, all GLocString properties or JSOn properties of your schema will be automatically translated when their resolvers return things containing LocStr instances.

Then, as with the Express.js explanation, jump to Generate translations section to know how to refresh your translations 🙂

A simple version of this example is here (nb: it provides hard-coded translations, not using translation files)

Generating translations

If you're here, I'll assume that you have read one of the previous two sections.

Lets say you now want to add support for French. First, add something like this in the "scripts" section of your package.json:

{
   "scripts": {
       "collect": "smartloc collect --format=json --locales=fr-FR --defaultLocale=en-US --generateDefault"
    }
}

When you run npm run collect, it will (re)generate two files in the i18n directory:

en-us.json : You can forget this file, it is here for reference because you put the --generateDefault option in commandline, and you can provide translations in it (in which case the actual string in code will never reach your client), but you can leave it as it.
fr-fr.json : This is where you'll have to put your translations.

In these files, translations are grouped by the left dot of strings IDs.
For instance, if you had:

loc`Automatic ID`;
loc('someId')`Some ID string`;
loc('someGroup.someId')`Some grouped ID string`;

It will generate something like this:

{
   "$default": {
       "<sha of your string>": { "source": "Automatic ID" },
       "someId": { "source": "Some ID string" }
    },
    "someGroup": {
        "someId": { "source": "Some grouped ID string" }
    }
}

Just add a corresponding "target" to each "source", and you'll be good to go. For instance:

{ 
  "source": "Some grouped ID string",
  "target": "Une chaine avec ID groupé"
}

Then, at startup, just tell smartloc where it should look for translations:

import {loadAllLocales} from 'smartloc';
import path from 'path';

// load all locales in the i18n directory
// ... you could also use loadLocale() to only load one locale file.
loadAllLocales(path.resolve(__dirname, 'i18n'));

🎉 Here it is ! If your translation files are OK, you'll have a fully functioning multi-language API server !

I will let you guess how to add more than one translation :)

Wrapping up

This introduction scratched the surface of what can be done with this lib.

We've been using it for months @ justice.cool and I must say I am pretty happy with it.

Before anyone comments something like "you know, there are other libs that" ... I know that there already are plenty of other i18n libs, but I felt like developping a simpler one, which felt good to me. If it doesnt to you, well... that's bad luck mate. Keep using those monsters out there.

To know a bit more about advanced usages (transform strings, storing translatable strings, manual translations, ... refer to smartloc repo ), or open an issue, I'll be glad to answer it.

How to really unit test code that uses a DB.

Olivier Guimbal — Fri, 31 Jul 2020 16:04:01 +0000

TLDR

I recently wrote a small js lib that allows you to emulate an in-memory version of Postgres.

It is pure js (it works both in browser or with nodejs), and compatible with most query frameworks/ORMs.

You can play with it on pg-mem playground.

The problem with unit testing and databases:

pg-mem is compatible with several major ways to connect to a db, but lets assume you are using pg-promise.

When using a DB, you could have methods like

const getUsers = () => db.many('select id, name from users');
const addUser = name => db.none('insert into users(name) values ($1)', [name]);

If you want to unit test things that uses those methods, you would have three options:

reimplement a mock "user-service" which replicates what the db essentially does
hook your request executor (pg-promise, in this case) and tell it "ok, i expect this request to return that".
create a new clean database on each test run (!!)

Either way, this is not reliable nor sustainable as it can lock down implementation details in your unit tests, your mocks can be bugged, or the complexity of testing could explode as your project grows.

The solution I came up with

In short, I reimplemented a pure js in-memory version of Postgres.

You can play with it here - notice that there are no outgoing queries as you type SQL, but you'll still get the results... yea... sql db, in memory, even in browsers.

It involved developping two quite heavy parts:

A postgresql syntax parser
A replication of the PG database engine.

But in the end, it works quite well:

import {newDb} from 'pg-mem';
const db = newDb();
const results = db.public.many(`create table test(id text primary key, value jsonb);
         insert into test values ('key', '{"data": "hello"}');
         select value->>'data' || ' world' from test;`);
console.log(results) // guess what this prints ? :)

The only thing you will have to do to unit test your code that issues actual SQL queries: Replace your usual request framework with an instance of it which is bound to a pg-mem instance instead of an actual database !

No more thinking about how-the-hell-am-i-going-to-unit-test-that.

See github repo for examples.

Benefits

Performance

If you used to run your unit tests against a DB, know that pg-mem is really performant, and implements b-tree indexing.

Coupled with vscode+mocha+hmr, pg-mem is the perfect match to reach this nice ultra fast development loop, without compromising on your testing quality.

(nb: this is a shameless plug - i'm the forker who implemented hmr support for vscode mocha explorer)

This is how running thousands of sql requests feels like with pg-mem and vscode+mocha+hmr :

Actual SQL requests unit-testing

pg-mem parser is not perfect and can fail if you use fancy features, but it is good enough to handle most common features, and it can help you to unit test your requests syntax (if you write sql directly), and test your codes' actual behaviour against a database without having to rely on an actual database (which brings hell in your codebase: stateful unit tests).

Index usage unit testing.

(experimental) pg-mem has its own implementation of indexes. It is far form being perfect, and does not match the way-more-clever behaviour of an actual posgres instance, but it can tell you when there are things that are obiously wrong... you can create a unit test to check that a specific request uses an existing index, for instance. If pg-mem uses an index, I think PG will be clever enough to use it also :)

Database immutablility

pg-mem uses immutable data structures under the hood.
This means that you can restore a your database at any previous point in time, with no performance overhead. Quite useful (see ORM section below for an example).

If you use an ORM

Most ORMs support creating the schema based on what you described of it => If you use such an ORM, I recommend this pattern (described here using Typeorm):

// test-db.(js|ts)
import {newDb} from 'pg-mem';

let db = newDb();
let backup;
let orm;
export async function createOrm() {
    // close old instance
    // (typeorm has static stuff which prevents intiating multiple connection)
    await orm?.close()

    // create new instance
    orm = await db.adapters.createTypeormConnection({
        type: 'postgres',
        entities: [...allYouEntitiesHere]
    });

    if (!backup) {
        // this is the first test to run using this schema
        // ... lets create your tables
        //   (if you have thousands, this could be heavy)
        await orm.synchronize();

        // custom requests ? fill some shared data, etc...
        await orm.doSomething();
        await db.query('some sql');

        // Then, create a backup of this empty database with created schema
        // nb: this is instantaneous (o(1))
        backup = db.backup();
    } else {
        // Okay, a previous test already create the DB schema
        // => lets restore data as it was after schema creation
        // nb: this is instantaneous (o(1))
        backup.restore();
    }
    return orm;
}

Then use this createOrm() function in all your unit tests instead of creating an instance of your ORM the traditional way.

This way, you will have a clean database on each test run, for free ! (it really is performant in practice...)

Work in progress: The future

I intend to develop serveral features in the future, like:

Automatic table creation (i.e. if a table does not exist, the db will guess the table to create when you perform insert requests).
Advanced features of postgres (gin indices, actual introspection, stored procedures, ...)

It currently supports mocking pg, pg-native pg-promise and typeorm (the latests are using the two firsts, so their "mock" only are hooks to replace real pg connection with fake pg instance in their internal mechanisms)

See repo for sample usages. Do not hesitate to post issues or comments, and happy unit testing :)

oguimbal / pg-mem

An in memory postgres DB instance for your unit tests

pg-mem is an experimental in-memory emulation of a postgres database.

❤ It works both in Node or in the browser

⭐ this repo if you like this package, it helps to motivate me :)

👉 See it in action with pg-mem playground

📐 Usage

Using Node.js

As always, it starts with an:

npm i pg-mem --save

Then, assuming you're using something like webpack, if you're targeting a browser:

import { newDb } from "pg-mem";

const db = newDb();
db.public.many(/* put some sql here */);

Using Deno

Pretty straightforward :)

import { newDb } from "https://deno.land/x/pg_mem/mod.ts";

const db = newDb();
db.public.many(/* put some sql here */);

Only use the SQL syntax parser

❤ Head to the pgsql-ast-parser repo

⚠ Disclaimer

…

View on GitHub

DEV Community: Olivier Guimbal

Introducing ngx-react : 🅰️Angular + ⚛️React interoperability without pain.

📐 Setup

Use 🅰️ in ⚛️

Use ⚛️ in 🅰️

Services

Wrapping up

Learn functional programing with me - Part 1 : Language choice

🤔 Why would you care ?

🤪 Why do I do that ?

🎯 Specifications - what should it do ?

👅 Language

1️⃣ Purescript

✔ PROS:

💥 CONS:

📚 Framework:

2️⃣ ELM

✔ PROS:

💥 CONS:

📚 Framework:

3️⃣ ReasonML/ReScript

✔ PROS:

💥 CONS:

📚 Framework:

4️⃣ Haskell

✔ PROS:

💥 CONS:

📚 Framework:

5️⃣ Clojure(Script)

👋 Conclusion

Haskell as a first timer - Am I missing something ?

💖 First looks - The (very) good parts

🥪 Frustration 1 - Stack configuration

💥 Frustration 2 - Stack error messages

🤼 Frustration 3 - Maintainers ?

📚 Frustration 4 - Documentawhat ?

👉 Conclusion - Please enlighten me

My favorite pages on the whole internet

localStorage vs cookies: the "tabs vs spaces" sterile debate of web development 🙄

If someone owns you, someone owns you.

Cookies also have their drawbacks

XSS / Malicious JS dependencies: The easy fix.

Which one to use then ?

Zero delay development & unit testing iterations

TLDR

What is HMR, and how can it be useful ?

Neat. How do I setup HMR ?

Also make my unit tests fast again, please

To set it up

A tip to yet improve your iteration loop experience

How to never touch your mouse again 🐭

Olivier Guimbal ・ Aug 18 '20 ・ 3 min read

How to never touch your mouse again 🐭

VIM ? Well... no thanks.

What if I dont wanna spend 32752 hours learning/configuring VIM ?

Configuring vscode alone

System-wide configuration using AuthoHotKey (Windows only, sorry)

Other utilities

Jumpy

Switcheroo (Windows only)

For those who want VIM bindings:

[edit] Vimium

i18n - Express/Apollo GraphQL server translation made simple

Table of contents

The problem

The smarloc approach.

Express.js: How to setup ?

Apollo GraphQL: How to setup ?

Generating translations

Wrapping up

How to really unit test code that uses a DB.

TLDR

The problem with unit testing and databases:

The solution I came up with

Benefits

Performance

Actual SQL requests unit-testing

Index usage unit testing.

Database immutablility

If you use an ORM