DEV Community: João

Keyboard Layouts and Cognitive Overhead

João — Tue, 22 Nov 2022 22:18:09 +0000

Before I start talking about my experience with mechanical keyboards and what it has to do with Cognitive Overhead, it's important to explain that the latter is.

When explaining what Cognitive Overhead means, David Lieb uses the definition coined by web designer and engineer in Chicago David Demaree: Cognitive Overhead — “how many logical connections or jumps your brain has to make in order to understand or contextualize the thing you’re looking at.”
Source: Cognitive Overhead, Or Why Your Product Isn’t As Simple As You Think

The first mechanical keyboard I tried was a cheaper Coolermaster one. Apart from not having the numerical keypad, it was a conventional keyboard layout. I realized back then I do not miss the numpad at all because I pretty much never use it anyway. So, it's actually one less thing to worry about, and thus less cognitive overhead to me.

Afterwards, I decided to use an Ultimate Hacking Keyboard. It was a split keyboard - literally, the left and the right sides can be split, joined by one cable. It was a bit of cognitive overhead, but not that much. I could get used to it in a couple of days. The lack of separate arrows and function keys got more time to get used to, though. Fortunately, it had a wonderful "mouse mode" which let me use the keyboard as a mouse. I ended up learning to use the mouse mode instead of the arrow keys. So, a kind of tradeoff: the cognitive overhead of having to learn the positions of the different keys was compensated by using the mouse mode, which was simpler.

Unfortunately, I spilled coffee all over my UHK, and couldn't save it. I had to buy another keyboard, and decided to try... Moonlander Mark I. And damn, that was a cognitive overhead nightmare to me. The columnar layout was the first one, but not so much: I surprisingly got used to it in a matter of hours. Having to use thumb keys to get access to arrows and function keys was a bit too much to me, though. I know other people get used do it, but I was actually getting scared of hitting the wrong key and press delete instead of Home/End for example. The thumb keys were very uncomfortable as well, so yet another cognitive overhead issue to me. I decided to sell it and buy a... Dygma Raise. Why didn't I pick a more conventional keyboard? I don't know, I just wanted to try something different.

Dygma Raise is amazing. Build quality is top-notch, it's a sturdy beast, it's easy to customize and completely programmable. The thumb keys were much better positioned and easier to use. I thought I was going to get used to it, but I slowly realized I actually did not like non-conventional keyboards at all! Needing to press a modifier key to get access to arrows, home/end, F1...F12 keys was slowly draining some mental health out of me. Why? You guessed it... cognitive overhead!

What I now understand is that I was fighting against decades of muscle memory. Using a more conventional keyboard layout for an hour is enough for me to get all my muscle memory back to normal. I bought a Logitech G912 TKL (TenKeyLess, meaning without the numerical pad because that's one thing I don't miss) this time. I'm not telling you to not use mechanical keyboards at all, but just keep in mind that cognitive overhead is a big thing that causes a lot of stress. It might pay off in the end, but sometimes the price is too high.

Vim/NeoVim as a (very) simple REST client

João — Thu, 15 Apr 2021 15:32:31 +0000

Whenever you need to test APIs, you can probably resort to nice GUIs like Postman or Insomnia. They let you easily create separate projects, separate API paths, and so on. I do not like to leave my editor so often, so sometimes I just want to do the API calls inside it. If you use Vim, you can just run cUrl, httpie or some other HTTP client and paste the output on your buffer.

The following function is very handy because you can use pretty much any shell command you want and the output will be handily updated in your editor.

function! Exec_on_term(cmd, pos)
  exec "normal! ma"
  let backup_a=@a
  let backup_b=@b
  let sep = "------"
  exec "normal! ?".sep."\<CR>jV/".sep."\<CR>k\"ay"
  exec "normal! /".sep."\<CR>jO"
  if a:pos == "next"
      exec "normal! O".sep
      exec "normal! jddkko"
  endif
  exec "normal! V/".sep."\<CR>kdO"
  let @b=system(@a)
  execute "put b"
  execute "normal! ?".sep."\<CR>jdd"
  exec "normal 'a"
  let @b=backup_b
  let @a=backup_a
endfunction
nnoremap <Leader>dr :call Exec_on_term("normal", "curr")<CR>
vnoremap <F6> :<c-u>call Exec_on_term("visual", "curr")<CR>
nnoremap <Leader>dn :call Exec_on_term("normal", "next")<CR>

For example, if you have the following buffer contents:

-----------
curl -H "Content-Type: application/json" \
-X POST  \
https://reqbin.com/echo/post/json \
-s -d '{"sample": "value"}'
-----------
output will be shown here
----------------

You just need to go anywhere between the first "-------" line and the second "------" line, and type <Leader>dr (in my Vim config, Leader is the comma character, so ,dr here. It will run the command and show the output between the second and the third "-------" lines:

----------------
curl -H "Content-Type: application/json" \
-X POST  \
https://reqbin.com/echo/post/json \
-s -d '{"sample": "value"}'
----------------
{"success":"true"}
----------------

If you change the command, it will replace the output. If you do not want to replace the contents, you can add a new entry by using <Leader>dn:

----------------
curl -H "Content-Type: application/json" \
-X POST  \
https://reqbin.com/echo/post/json \
-s -d '{"sample": "value"}'
----------------
{"success":"true"}
-----------
output will be shown here
---------------

You can also run any CLI command, like Python code by using python -c:

---------------------
python -c '
import os
print("this is a python script")
'
---------------------
this is a python script
---------------------

React: Criando Hooks Customizados

João — Tue, 11 Aug 2020 17:09:19 +0000

Uma das características mais importantes que um código pode ter é o reuso. É bom poder encapsular funcionalidades específicas em uma classe ou função. Esse é, na minha opinião, um probleminha com componentes de classe no React. Você precisa usar métodos do ciclo de vida do componente, como componentDidMount e componentWillUnmount. Fica mais difícil encapsular tudo isso. Você precisa alterar seus componentes, mudando a hierarquia da classe, adicionando contexts com providers ou algo do tipo. Não há algo que você possa simplesmente "plugar" no seu componente.

É aqui que o uso de componentes de função pode vir a calhar, já que os Hooks e Effects do React podem ser muito bem aproveitados. O objetivo deste pequeno artigo é mostrar como você pode utilizar encapsular específicas para sua aplicação lançando mão de Hooks. Por exemplo, o componente abaixo, extraído de um caso de uso real, permite ao usuário a entidade atual (um usuário, um aluno, um professor, uma empresa, etc):

export const FavoriteEntitiesSection = () => {
  const [favoriteEntities, setFavoriteEntities] = useState([]);
  const [currentEntityIsFavorite, setCurrentEntityIsFavorite] = useState(false);
  const currentEntity = useSelector((state) => state.currentEntity);

  const refreshFavoriteEntities = () => {
    FavoriteEntities.fetchCurrent().then(setFavoriteEntities);
  };

  useEffect(() => {
    refreshFavoriteEntities();
    return () => {
      FavoriteEntities.someCleanupAction();
    };
  }, []);

  useEffect(
    () => {
      const isFavorite = favoriteEntities.some((item) => item.id === currentEntity.id);
      setCurrentEntityIsFavorite(isFavorite);
    },
    [favoriteEntities, currentEntity],
  );

  const handlePinEntityButtonClick = () => {
    FavoriteEntities.addEntity({
      currentEntity,
    }).then(refreshFavoriteEntities);
  };

  const handleRemoveEntity = (id: string): void => {
    FavoriteEntities.removeFavoriteEntity(id).then(refreshFavoriteEntities);
  };

  return (
    <div>
      <div>Id: {currentEntity.id}</div>
      <div>Name: {currentEntity.name}</div>
      <div>
        <button disabled={currentEntityIsFavorite} onClick={handlePinEntityButtonClick}>
          Pin Entity
        </button>
      </div>
      <div>
        {favoriteEntities.map((entity) => (
          <div>{entity.name} <button onClick={() => removeEntity(entity.id)}>Remove</button></div>
        ))}
      </div>
    </div>
  );
};

E se nós quisermos usar esses favoritos em outro lugar? Poderíamos simplesmente incluir esse componente inteiro, mas pode ser que nós queiramos somente a listagem, pode ser que queiramos somente saber se a entidade atual está nos favoritos, etc. Isso pode ser resolvido incluindo tudo no Redux? Sim, mas nem sempre isso é desejável. Vamos refatorar esse código para que a funcionalidade de "favoritos" fique encapsulada:

function useFavoriteEntities(loadAtMount = true) {
  const [favoriteEntities, setFavoriteEntities] = useState([]);
  const [currentEntityIsFavorite, setCurrentEntityIsFavorite] = useState(false);
  const [isRefreshing, setIsRefreshing] = useState(false);
  const currentEntity = useSelector((state) => state.currentEntity);

  const refreshFavoriteEntities = () => {
    if (!isRefreshing) {
      setIsRefreshing(true);
      FavoriteEntities.fetchCurrent()
        .then(setFavoriteEntities)
        .finally(() => setIsRefreshing(false));
    }
  };

  useEffect(() => {
    if (loadAtMount) {
      refreshFavoriteEntities();
    }
    return () => {
      FavoriteEntities.someCleanupAction();
    };
  }, []);

  useEffect(
    () => {
      const isFavorite = favoriteEntities.some((item) => item.id === currentEntity.id);
      setCurrentEntityIsFavorite(isFavorite);
    },
    [favoriteEntities, currentEntity],
  );

  const saveCurrentEntity = () => {
    if (!currentEntityIsFavorite) {
      FavoriteEntities.addEntity({
        currentEntity,
      }).then(refreshFavoriteEntities);
    }
  };

  const removeEntity = (id) => {
    if (currentEntityIsFavorite) {
      FavoriteEntities.removeEntity({
        id,
      }).then(refreshFavoriteEntities);
    }
  };

  return {
    favoriteEntities,
    refreshFavoriteEntities,
    currentEntityIsFavorite,
    saveCurrentEntity,
    removeEntity,
  };
}

export const FavoriteEntitiesSection = () => {
  const {
    favoriteEntities,
    currentEntityIsFavorite,
    saveCurrentEntity,
    removeEntity,
  } = useFavoriteEntities(true);

  const currentEntity = useSelector((state) => state.currentEntity);


  const handlePinEntityButtonClick = () => {
    saveCurrentEntity();
  };

  const handleRemoveEntity = (id: string): void => {
    removeEntity(id);
  };

  return (
    <div>
      <div>Id: {currentEntity.id}</div>
      <div>Name: {currentEntity.name}</div>
      <div>
        <button disabled={currentEntityIsFavorite} onClick={handlePinEntityButtonClick}>
          Pin Entity
        </button>
      </div>
      <div>
        {favoriteEntities.map((entity) => (
          <div>{entity.name} <button onClick={() => handleRemoveEntity(entity.id)}>Remove</button></div>
        ))}
      </div>
    </div>
  );
};

Perceba como o componente deixa de se preocupar com a lógica em torno dos favoritos, inclusive com a atualização automática: tudo é feito dentro da função. Fica até mais fácil dar uma incrementada nas funcionalidades, como eu fiz no exemplo acima:

Chamadas repetidas ao refreshFavoriteEntities não vão gerar chamadas desnecessárias ao serviço.
Tentativas de salvar um favorito que já foi salvo não geram duplicações

Além disso. se em algum outro componente precisar somente da listagem, basta usar:

const { favoriteEntities } = useFavoriteEntities();

Espero que esse exemplo ajude a entender como tirar vantagem dos Hooks no React! Afinal, não pode ser só choro e ranger de dentes, de vez em quando tem que haver alguma vantagem.

What to do when rebase goes wrong?

João — Fri, 03 Jul 2020 15:02:09 +0000

Git (and other DVCS such as Mercurial) makes branches much easier than the previous, non-distributed versions. It is also very powerful, but sometimes things can go really wrong. One common issue is using git rebase when a branch is outdated and points to an old commit from master. Older branches can lead to a lot of conflicts, making rebase a nightmare. The purpose of this blog post is to show you some ways you can save time and probably your sanity using rebase. This is a specific to a simple branch rebase that's often needed when the branch is based on a commit that's just too old.

The simplest solution is to just use git merge, but there are some reasons why you may not want to do that:

It pollutes the tree with merge commits. Depending on the number of commits, it can look quite messy. In my case, the repository constantly receives hundreds of commits in a single day.
If you're using Pull Requests or Phabricator diffs, using git merge is not recommended.

Suppose we have a feature branch. First, you need to the commit at master that started your branch. In the following image, it's C2

You can find it by using the git merge-base command:

$ git merge-base master feature
c2ff9421e78bd5e8f5d9c72702439f989e3f10e0

Now that we have the base commit for the branch, let's generate a patch for your branch:

$ git diff --patch c2ff9421e78..feature > feature.patch

Now that you have your patch for the whole branch, switch to master, retrieve the latest changes and create a new branch

$ git switch master
$ git pull
$ git checkout -b feature-rebase-temp

What we do now is just apply the patch. What difference does it make? Well, it will expose absolutely all conflicts right away, instead of complaining about at conflicts at each single commit of the feature branch:

$ patch -p1 --merge < feature.patch
... resolve all conflicts
$ git commit -m "Your message"

This branch is now corresponding to the post-rebase state of your feature branch. If you are okay with not having the commit history of your feature branch, you can just make the feature-temp branch your feature branch:

$ git branch -m feature feature-outdated
$ git branch -m feature-temp feature

You lose the previous history, but in my experience this is the safest route when your branch and master differ way too much, you don't risk losing changes and have all the conflicts at once.

New Life, new Horizons, New Job

João — Fri, 04 Oct 2019 14:00:11 +0000

I've been working at SERPRO for 10 years. Ten years is a lot of time in the IT field. Fortunately, I learned a lot about development, working with people, working with bureaucracy, and many, many other professional lessons. Work wasn't bad, actually. It was frustrating sometimes, but the salary was nice, coworkers were great people and I had some freedom to study and opt for new technologies, at least given the limits of a large public company. Oh, and I had job stability, which is the dream of the vast majority of the Brazilian. The political landscape in Brazil is ridiculously unstable, and so is the economy.

I felt that something was missing, though. You know that gut feeling that you should be doing something else? So, I decided to assess my skills in the market, see how I would do out of Serpro. I was quite surprised to see I was quite qualified, actually! I never wanted to be the kind of guy that lives in the public sector, afraid of losing my job and not being able to relocate without a major hit on my salary.

As everyone in the world probably knows, the Brazilian government is not something we are proud of. They are also not exactly fond of owning a public IT company, so they want to privatize it. It's a good thing that I already got a good job proposal before I could quit Serpro.

So, goodbye Serpro, and welcome, BairesDev! I'm quite happy with my new job, and I hope I can bring my skills to the table. This feels almost like a new life to me. After all, it's been 10 years in the public field, and I fortunately didn't lose my mojo.

The Myth about Javascript ecossystem's descent into hell

João — Wed, 05 Jun 2019 13:52:16 +0000

Warning: grumpy programmer that's been working with Javascript since Netscape 4 (1999 I guess)

I'm becoming a different kind of an old fart: the one who doesn't really miss the good ol' times when we didn't have so many any JS libraries and frameworks and everything was so simple (or so they say). I would take new JS technologies over the old, pre-NPM-projects era any day.

Yeah, I know it's sometimes frustrating to need to download zillions of dependencies so we can build a simple "Hello World" app. I can easily see the point of using Vanilla JS or jQuery even for greenfield projects. Someone who has pretty much only worked with JS libraries and frameworks such as React, Angular, Vue, etc may find jQuery or vanilla JS a breathe of fresh air. It may seem to be a great idea. After all, who needs so many external dependencies when we can just fetch data and render smaller jQuery UI components?

So, you just start rewriting that old overdone code with small JS files and simple HTML. After a couple of months/years later, you start realizing there's something not quite right about your code. You spot Javascript monsters breaking and turning the state into a spaghetti dragon firing meatballs. Then, one may think "what if we create a library that kind of lets us control page state more easily? Let's give it a name that sounds like it reacts to changes". Ring any bells?

There is a bright side to opting for vanilla JS, though. One may find, indeed, several cases where using a library is not necessary. Do you really need a "is-number-equals-to-zero" library? What about "return-false-when-object-equals-to"? Don't forget that maybe there is a reason why people choose NPM projects, etc, even guys that do web development since we didn't even have AJAX and jQuery was a pipe dream.

Vanilla JS or plain jQuery are great for really small scripts, but remember:

Most apps are usually seemingly small and trivial at first
When you project grows beyond a certain point, vanilla JS may give you headaches
Know as much about vanilla JS as possible, sometimes you can just use it instead of some library.

Using Svelve for Plone add-ons

João — Mon, 03 Jun 2019 19:46:30 +0000

Zope/Plone bashing follows. If you like Zope/Plone, that's okay, just
skip the first paragraph and I promise you'll read no bashing!

I don't like Plone. Okay, actually, I don't like Zope/ZODB. It's overly complex, VERY inneficient, difficult to maintain, quite fragile. Plone itself is a miracle. The people behind it should be canonized as saints and revered as geniuses. They managed to do something actually usable with the mess that is Zope. Why I'm bashing Zope if I'm going to talk about Plone? Well, I have a job. My job is not to only work with technologies that I like. My job is to work with technologies that I have to.

End of Zope/Plone bashing, carry on!

The problem

I needed to develop an add-on which included a view that calls an internal server to search for specific results and render them differently depending on the context. There's not much to it, except the UI, which is not too complex, but complex enough for me to not like using vanilla JS, jQuery or simple ZPT templates. I first tried React, because it Plone 6 will ship with a React-based frontend. I managed to make it work with Plone 5, for then I had a problem: I still needed to support Plone 4, and then I found my solutions too bug-prone.

A solution: Svelte

I thought to myself: "What I need is something that doesn't require any external dependency at all". Then I remembered reading something about Svelte, because, well, it promised to be a "disappearing" library that outputs just plain Javascript that I would just need to include in my add-on. Does it work? Turns out it does! Here is a sample:

<script>
    export let name;
</script>

<style>
    h1 {
        color: purple;
    }
</style>

<h1>Hello {name}!</h1>

When you build it, the output is a Javascript file that does not need Svelte itself: it's a self-contained file that can easily be used inside a page with a simple JS entry. The CSS is split into a separate file as well.

<link rel="stylesheet" href="my-built-app.css" />
<script type="text/javascript" src="my-built-app.js"></script>
<div id="appContainer"></div>
<script>
    // target is the element where the component will be rendered
    // props are the properties that the components need
    const app = new App({
        target: document.getElementById("appContainer"),
        props: {
            name: "Elvis Presley"
        }
    });
</script>

Hands-on: Using Svelte inside an add-on

For this hands-on, you will need:

The latest Node.js version. I highly recommend using NVM
A Plone installation that includes a develop.cfg configuration
Knowledge on how to develop add-ons using Mrbob

Create a sample add-on product

First, create a sample add-on product using mrbob inside the src directory of the plone instance:

mrbob -O svelte.sample collective.mrbob:addon

Then, add it to the develop.cfg file:

...
[sources]
svelte.sample = fs svelte.sample
...

eggs +=
    ...
    svelte.sample

Add the initial structure

For now, let's just add a file inside src/svelte/sample/browser/static/sample.js that will output something to the console so we can tell everything's ok for now. We will replace it with the component later:

console.log("svelte.sample Javascript included");

Add a View

The Svelte sample will be run inside a simple view, so, let's first add it to configure.zcml:

  ...
  <browser:page
      name="svelte-sample"
      for="*"
      permission="zope2.View"
      class=".views.SampleView"
      />
  ...

The view is inside the views module, so, let's create it inside src/svelte/sample/views.py:

from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile

class SampleView(BrowserView):
    index = ViewPageTemplateFile('templates/sample.pt')

    def render(self):
        return self.index()

    def __call__(self):
        return self.render()

We now need the template, so, create the file src/svelte/sample/templates/sample.pt:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:metal="http://xml.zope.org/namespaces/metal"
      xmlns:tal="http://xml.zope.org/namespaces/tal"
     metal:use-macro="context/main_template/macros/master">

<metal:block fill-slot="javascript_head_slot">
  <script type="text/javascript" src="++plone++svelte.sample/sample.js" />
</metal:block>

<metal:block fill-slot="content-core">
  Nothing here yet
</metal:block>

</html>

Now we have a working add-on. If you run the Plone instance, install it and open the @@svelte-sample view, it will show a page containing "Nothing here yet", and the console will show 'selvte.sample Javascript included'. The add-on itself won't depend on anything else, but we obviously need to create the Svelte components. Thus, we need to create a Svelte project.

Create the Svelte project

Creating the project itself is easy. We will be creating the JS project inside our add-on source for this hands-on. Inside the project's root directory, run the following commands:

npx degit sveltejs/template component
cd component
npm install

Now, modify the file component/src/App.svelte:

<script>
    export let name;

    $: uppercaseName = (name || "").toUpperCase();
</script>

<h1>Hello {uppercaseName}!</h1>

Before we build the project, we need to tell the builder to just export your components we built, by modifying component/src/main.js

import App from './App.svelte';

export default {
  App
}

Then, let's build the project and copy the resulting bundle.js file:

npm run build
cp public/bundle.js ../src/svelte/sample/browser/static/sample.js

Add the Svelte component to the view

That's it, now the App component is going to be available when we include our sample.js file inside the Plone's view page. Change the src/svelte/component/templates/sample.pt file to:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:metal="http://xml.zope.org/namespaces/metal"
      xmlns:tal="http://xml.zope.org/namespaces/tal"
     metal:use-macro="context/main_template/macros/master">

<metal:block fill-slot="javascript_head_slot">
  <script type="text/javascript" src="++plone++svelte.sample/sample.js" />
</metal:block>

<metal:block fill-slot="content-core">
  <div id="sampleContainer"></div>
  <script type="text/javascript">
    const sample = new app.App({
      target: document.getElementById("sampleContainer"),
      props: {
        name: "Person"
      }
    });
  </script>
</metal:block>

</html>

Now, if you open the @@svelte-sample view, it should show a big Hello PERSON!. No external includes needed.

Bottom Line

I'm not saying you should just use Svelte for every single add-on. If you can target Plone5+, you could probably use React. If you, however, plan to support Plone 4 and/or don't want to rely too much on specific dependencies, it may be a good idea do pick Svelte. Just remember that what Svelte does is not to embed other dependencies inside the resulting JS build. So, my advice is to pick Svelte if you can live without other dependencies and pick React for anything else.

Why I chose Akita over NgRx

João — Tue, 09 Apr 2019 16:44:51 +0000

I really like the Redux concept. It allows developers to avoid state manipulation to be spread across the application, leading to difficult to detect inconsistencies, specially when dealing with asynchronous events such as calls to HTTP services. It is not, however, an easy concept to grasp. It may look like an overthought solution that creates more troubles than it solves. Anyway, I decided to give NgRx a try a couple of months ago. And it wasn't a pleasant experience. Let me tell you why.

Too much boilerplate

Let's start with the boilerplate issue. Whenever I needed to use NgRx for a specific part of my webapp, I had to:

Create a set of actions
Create a reducer function with a big and ugly switch statement
Add the reducer to the StoreModule.forRoot or StoreModule.forFeature call.
Call theselect function in my component or create selectors to get the current state.
Call the dispatch function to dispatch an action.

What if I needed to fetch data from a service? Well, then I'd have to:

Add an action that will be dispatched when data needs to be fetched
Add an action that will be dispatched when the call finished successfully
Add an action that will be dispatched when the call fails
Add an Effects class that will call the data fetch service itself and do the action dispatching
Add the Effects class to the EffectsModule call

It's not a big problem if it's not often needed. Data feching is what I mostly do, though! Effects can become huge and not so easy to maintain.

Too many concepts

I have to admit, a part of our problem is that developers only knew AngularJS (1.5), not Angular (2+). They had to learn about components, modules, DI. I know AngularJS had them before, but Angular (2+) is so different it feels like a new framework. They also had to learn about RxJS, Observables, and other concepts that aren't trivial. And then, suddenly, they also had to learn about Actions, Dispatchers, Reducers, Effects, Selectors! Maybe I should've seen it coming, but even if they already felt comfortable with Angular, it seems that those concepts aren't easy to grasp unless you knew Redux(-ey) libraries before.

NgRx feels alien to Angular

Whenever I was using NgRx, I felt like maybe it could make more use of Angular. For example, instead of the big and ugly reducer, decorators should be used by default. Some libraries try to solve that problem, but they felt subpar to me, and they sometimes introduced even more complexity, like needing specific work to avoid problems with AOT compilation. If you're using NgRx, I recommend ngrx-actions.

My coworkers had a very, very difficult time "getting" NgRx, and they spent more time trying to understand NgRx along with Angular than developing the application itself. So, we decided to drop NgRx entirely and letting everyone do as they please, because there was a deadline to meet.

Dropping Redux? Not yet!

I didn't quit trying do use Redux-style libraries in my app, but I decided to try the alternatives. Two of them looked more mature and well-tested:

NgXs: More simple than NgRx, but it still had some specific parts that irritates developers, such as the need to declare an Action and corresponding specific dispatch method in a separate place.
Akita: Even simpler than NgXs. Instead of actions and dispatchers, just a plain service, even for async calls. Queries are plain observables.

The winner: Akita

Now, let's see what it takes to introduce Akita in a specific project

Create a store as a class extending EntityStore
Create a service that injects the store and expose actions as service methods. No need for actions, reducers, dispatchers, annotated methods, etc. Just plain methods that updates the state.
Create a class extending QueryEntity so we create selectors
Need to call a HTTP service? No problem, just create a service method.

It could be even easier, but this seems easy enough I can now talk about it without raising many eyebrows. Maybe I will give NgRx or NgXs another chance, but for now I'll stay with the simpler choice.