Lean Pinia stores

Three years ago – time files – I wrote a hack to remove the boilerplate fields from a Pinia store. It worked well.

This morning, writing work stuff, I wrote a lightweight wrapper to Pinia’s defineStore, with the primary intent to remove the manual string ID which needs to be given. After the initial TypeScript brouhaha, it went so well that I was able to fully integrate the boilerplate strip with Omit, which is a solution even less intrusive than the one I wroten 3 years ago.

import {_ActionsTree, _GettersTree, defineStore, DefineStoreOptions, Pinia, StateTree, Store, StoreGeneric} from 'pinia';

let nStore = 0;

type LeanStoreDef<Id extends string = string, S extends StateTree = StateTree, G = _GettersTree<S>, A = _ActionsTree> = {
	(pinia?: Pinia | null | undefined, hot?: StoreGeneric): Omit<Store<Id, S, G, A>,
		'$id' | '$dispose' | '$onAction' | '$patch' | '$reset' | '$state' | '$subscribe' | '_customProperties'>;
	$id: Id;
}

// eslint-disable-next-line @typescript-eslint/no-empty-object-type
export function newStore<Id extends string, S extends StateTree = {}, G extends _GettersTree<S> = {}, A = {}>(
	options: Omit<DefineStoreOptions<Id, S, G, A>, 'id'>,
): LeanStoreDef<Id, S, G, A> {
	return defineStore(('siorg-store-' + ++nStore) as Id, options);
}

Usage is just exactly what I had in mind:

const useNames = newStore({
	state: () => ({
		names: [] as string[],
	}),
	getters: {
		count: state => state.names.length,
	},
	actions: {
		add(name: string): void {
			this.names.push(name);
		},
	},
});

Zustand, devtools and immer wrapper, pt. 3

In another epiphany of the morning of this December 31, I enhanced my previous utility function to create Zustand stores, including devtools and immer middlewares:

import {create, StateCreator, StoreApi, UseBoundStore} from 'zustand';
import {devtools} from 'zustand/middleware';
import {immer} from 'zustand/middleware/immer';

type ZustandActions<T extends object, U extends object> = StateCreator<
	T,
	[['zustand/devtools', never], ['zustand/immer', never]],
	[['zustand/immer', never], ['zustand/devtools', never]],
	U
>;

/**
 * Creates a Zustand store with state, computed and actions.
 */
export function createStore<
	T extends object,
	U extends object,
	C extends Record<string, (s: UseBoundStore<StoreApi<T>>) => void>,
> (
	{
		state,
		computed = {} as C,
		actions = {} as ZustandActions<T, U>,
	}: {
		state: T;
		computed?: C;
		actions?: ZustandActions<T, U>;
	},
) {
	const store = create(
		devtools(
			immer(() => state),
			{name: Math.random().toString(36).slice(2), serialize: true},
		),
	);

	if (import.meta.env.DEV) {
		for (const name in computed) {
			if (!name.startsWith('use'))
				throw new Error(name + ' is a hook, and its name must start with the word "use".');
		}
	}

	return {
		use: store,
		...computed,
		...actions(store.setState, store.getState, store),
	};
}

The key improvement here is that computed functions will be 100% reactive, because they’re simple hooks attached to the store object – they work like ordinary hook functions:

const bearStore = createStore({
	state: {
		bears: 0,
	},
	computed: {
		useHasBears: () => bearStore.use(s => s.bears > 0),
	},
	actions: (set, get) => ({
		increasePopulation(): void {
			set(state => {
				++state.bears;
			});
		},
	}),
});

function App() {
	const bears = bearStore.use(s => s.bears);
	const hasBears = bearStore.useHasBears();

	return <div>
		<span>{bears} - {hasBears}</span>
		<button onClick={() => bearStore.increasePopulation()}>
			Change
		</button>
	</div>;
}

I’m in awe looking at such a small function yielding such a great usability.

Multiple className values in React, pt. 2

When dealing with an important React project at work, I was manipulating multiple CSS Modules class names with a function I wrote 2 and a half years ago, accepting an object for conditionals.

The early hours of the morning of this last day of the year brought me an idea for a shorter, simpler syntax that works better for imported CSS Modules names:

/**
 * Generates the `className` attribute with the given class names.
 *
 * @example
 * cn( 'abc' );
 * cn( 'abc', 'def' );
 * cn( 'abc', ['def', true] );
 */
export function cn(...items: (string | null | undefined | [string, boolean])[]): string {
	let fin = '';
	for (let i = 0; i < items.length; ++i) {
		const item = items[i];
		if (item === null || item === undefined) {
			continue;
		} else if (typeof item === 'string') {
			fin += item + ' ';
		} else if (Array.isArray(item) && item.length === 2) {
			if (typeof item[0] === 'string') {
				if (item[1]) fin += item[0] + ' ';
			} else {
				throw new Error(`cn() item #${i} is an invalid tuple: ${JSON.stringify(item)}`);
			}
		} else {
			throw new Error(`cn() item #${i} is invalid: ${JSON.stringify(item)}`);
		}
	}
	return fin.length ? fin.substring(0, fin.length - 1) : '';
}

And this new function covers all my current needs.

Download YouTube videos

These days I was transferring one of by band’s channel, and I needed to download a 1h34min long video. No web downloader worked properly.

While searching for an actual software, I found this Reddit post referring to a Python command line tool named yt-dlp. Basic usage is pretty straightforward:

yt-dlp.exe URL

My first try downloaded two files: MP4 and WEBM. The MP4 had no sound, and the WEBM was unplayable. My recently downloaded Vegas 22 didn’t seem to recognize this files. A warning message appeared, though:

WARNING: You have requested merging of multiple formats but ffmpeg is not installed.
The formats won't be merged

The repository README had an specific section labelled FFmpeg Static Auto-Builds, with a download link to Windows x64 binaries. The zip contains, among others, a bin directory with three executables. I extracted them in the same folder of the original executable – yt-dlp.exe –, and this time the download completed smoothly, with a single file with video and audio properly merged.

Excellent tool.

Goodbye my Universe

Today I finally parted ways with my long-time friend, my Ibanez Universe UV7BK green dots.

As far as I remember, I bought this guitar in 2008 amidst a craze of seven string guitars. I remember seeing an UV777BK on the TV and going nuts over that, even posting online at the old FCC forums. And by that time I joined a Dream Theater cover band, and I played solely this guitar. To this day, I still don’t know how I was able to play all that hard stuff on a seven string. Incredible young me.

The neck profile was truly great. I loved it. Pronounced shoulders, somewhat similar to the Suhr Modern Satin I had.

I remember trying to sell it 10 years ago or so, but I retreated.

After playing in a band where a seven string was demanded, and using a six string with a pitch shifter instead, I finally realized I don’t play sevens anymore. It must go. The original Ibanez wooden hardcase was wasted with mold, so I had to buy another one. Pretty bad fit, but anyway. The UV had grown mold in the neck too, but I cleaned. Maybe it will show up again in the future, who knows.

It was really hard to find someone to buy it. Professional sellers refused saying it’s hard to sell seven strings. In the end, I found someone to buy, and it posted it.

Goodbye, old friend.

Automating MSVC builds

While rewritting a few of my personal tools from Rust back to C++, I found myself willing to automate the build process. At first, I tried to invoke MSVC’s cl compiler directly, but it has proven to be absolute hell to do.

Eventually I stumbled upon the marvellous MSBuild tool, which is capable of understanding the .sln file and take all compiler and linker options from it:

msbuild foo.sln /p:Configuration=Release /p:Platform=x64

With that, I finally had the script to automate one build:

call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set APP="vscode-font-patch"
msbuild %APP%.sln /p:Configuration=Release /p:Platform=x64
move /Y x64_Release\%APP%.exe "D:\Stuff\apps\_audio tools\"
rmdir /S /Q x64_Release
pause

Then it was time to automate the release build of all my listed projects. And I found out how awkward .bat syntax is. Loop syntax is particularly horrifying. In the end, I was able to cook a script to automate my C++ builds:

call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat"

set APPS[0]="vscode-font-patch"

set "i=0"
:SymLoop
if not defined APPS[%i%] goto :EndLoop
call set APP=%%APPS[%i%]%%
cd %APP%
echo Building %APP%...
msbuild %APP%.sln /p:Configuration=Release /p:Platform=x64
move /Y x64_Release\%APP%.exe "D:\Stuff\apps\_audio tools\"
rmdir /S /Q x64_Release
cd ..

set /a "i+=1"
goto :SymLoop
:EndLoop
pause

C++20 variadics with abbreviated function template

Today, when working with my stripped C++ Win32 library – after the frustration with Rust’s long compile times in WinSafe –, I was trying to implement an overloaded variadic method, in order to get rid of initializer_list. Then I stumbled upon a great article which introduced me to the abbreviated function template feature of C++20, which I’m using.

This is an example:

int foo(std::wstring n)
{
	OutputDebugStringW(n.data());
	OutputDebugStringW(L"\n");
	return 43;
}

int foo(std::wstring n, std::convertible_to<std::wstring> auto... nn)
{
	foo(n);
	return foo(nn...);
}

The convertible_to concept is particularly interesting in narrowing the template type.

Fixing auth error with Cargo dependencies from GitHub

When trying to use a Cargo dependency straight from GitHub, an error was popping in the console:

failed to authenticate when downloading repository
* attempted ssh-agent authentication, but no usernames succeeded: `git`

The solution was to create a ~/.cargo/config.toml file, and then paste:

[net]
git-fetch-with-cli = true

Goodbye Go

On this morning, I just completely wiped away the Go compiler from my computer after finishing the Rust rewritten of my very useful ID3v2 editor, then written in Go. Now I have no tools written in Go anymore.

I consider I spent way too much time banging my head against the wall writing Windigo, trying to write a decent API. Go is way too limited, its lack of expressiveness won’t allow you to write any decent API more complex than a simple CRUD. And Win32 is hard. Windigo reached a point where there was nothing else I could do to make the API better – it was so bad it actually pushed me back to C++, where all my uneasiness started.

Another upsetting fact I noticed is that Go programmers tend to be unexperienced people. Beginners with trivial questions. Very demotivating.

I think anyone talking to me at this point would label me a “Go hater”. And as such, I can no more invest my scarce time in it. I remember in the early Windigo days I was completely in love with Go, with its first lines being written in my then girlfriend’s laptop. Yes, I installed the compiler there, and I don’t remember if it’s still there.

I plan to leave Windigo repo, and all its open issues, abandoned for a while. Maybe someone forks it and keeps it going. In the future, I will archive it, and I hope I never have to write Go ever again.

And that’s a shame, because “Windigo” is one of the coolest project names I ever came up with.

Linux recursive file searching

Searching recursively all files with the given extension:

find . -name "*.orig"

Searching all files containing the given text (source):

grep -Rn . -e "palavra"

Huge life saver.

Zustand, devtools and immer wrapper, pt. 2

On further researching of my previous idea of creating a Zustand + Immer wrapper, I found a very interesting technique straight from Zustand docs, where all the methods are simply free functions declared outside the store, called no store actions. I was already using this to declare private store methods, but it never occurred me to use it for all methods.

Since it officially has no downsides, I applied this idea to append the actions directly to the hook itself, so we don’t need to import each free function. The problem is that the hook has a couple methods itself, plus the inherent ones to any function object. So the result is very polluted. So I decided to adopt a convention of prefixing every action with $.

But conventions are easy to break. So I implemented a reduce to prefix each method name with #. But then TypeScript could not infer the type anymore, so I had to dig and type it manually with key remapping, and finally I got this implementation:

import {create, StateCreator} from 'zustand';
import {devtools} from 'zustand/middleware';
import {immer} from 'zustand/middleware/immer';
	
export function createStore<T extends object, U extends object>(
	initialState: T,
	actions: StateCreator<
		T,
		[['zustand/devtools', never], ['zustand/immer', never]],
		[['zustand/immer', never], ['zustand/devtools', never]],
		U
	>,
) {
	const store = create(
		devtools(
			immer(() => initialState),
			{name: Math.random().toString(36).slice(2), serialize: true},
		),
	);

	type WithPrefix<T> = {
		[K in keyof T as K extends string ? `$${K}` : never]: T[K];
	};
	const actionsOrig = actions(store.setState, store.getState, store);
	const actionsPrefixed = Object.entries(actionsOrig).reduce(
		(accum, [k, v]) => ({...accum, ['$' + k]: v}),
		{} as WithPrefix<typeof actionsOrig>,
	);

	return Object.assign(store, actionsPrefixed);
}

This creator allows us to call actions directly, without the hook. They’ll be automatically prefixed with $:

const useFoo = createStore({
	name: '',
}, (set, get) => ({
	setName(name: string): void {
		set(state => {
			state.name = name;
		});
	},
}));
	
function App() {
	const name = useFoo(s => s.name);

	return <div>
		<span>{name}</span>
		<button onClick={() => useFoo.$setName('Joe')}</button>
			Change
		</button>
	</div>;
}

That $ prefix gives me bad Vue vibes. Let’s see if I can get along with it, because I was able to develop a DX which is exactly what I was looking for.

Increase taskbar button width in Linux Mint 21

For my working VM, after ditching the sluggish Ubuntu 22 for the crazy good Mint Cinnamon 21, one of the customizations I wanted to make was the maximum width of the taskbar buttons. They seemed to narrow, while a lot of room was available.

After a couple minutes of searching, I found a direction in the Mint forums. The proposed solution is for Mint 20 – for Mint 21, it has a minor difference.

Edit, as root, the following file:

/usr/share/cinnamon/applets/grouped-window-list@cinnamon.org/constants.js

The value we’re after is MAX_BUTTON_WIDTH, which I increased from 150 to 210.

What caught my attention, though, is how all the layout building stuff is JavaScript.