I’ve been wasting way too much time, multiple times, looking for Brave’s cookie whitelist setting. So I’ll just leave it here, for reference to my future self. I found the reference on this Reddit post.
The settings are buried in:
Or, this direct link:
brave://settings/content/siteData
Today, Google Chrome officially disabled uBlock Origin extension. We can no longer enable it through any flags. I’ve been waiting for this moment to come for a while, and so it happened.
Today I finally uninstalled Google Chrome from my Windows computer.
Firefox is still my default browser, but I just installed Brave, which has the Chromium engine, because I have a feeling that it’s more performant than Firefox. However, I also have a feeling that Chrome itself is faster than Brave. Maybe Google has some code removed from Chromium and added only in Chrome, to intentionally make Chrome faster. Conspiracy theory, but who knows.
I used the portable version of Brave which felt strangely slow. I supposed that’s because I installed it on my D: drive, which is not SSD. Brave could not open magnet links, and so far, this new installation also cannot.
On my Android phone, I already have both Firefox and Brave. My issue with Brave is that it doesn’t support extensions, and SponsorBlock is become something I can’t live without.
Another issue is the disk space used by Chrome and Brave. My observations showed me that they top at somewhat 2.7 GB, which seems a lot. Coincidence or not, I also observed this for Firefox. My C: hard drive is running short these days, and until I buy myself a new computer, that’s all I have.
At last, I joined the bandwagon of the ex-Chrome users.
By default, Google Chrome on Windows stores all its data in:
C:\Users\USERNAME\AppData\Local\Google\Chrome\User Data
This folder seems to top around 2.5 GB, as I tested both in Chrome and Brave.
When digging the portable version of Brave, I found that it uses the --user-data-dir command line switch to store the data somewhere else – that’s the whole point of being portable.
This command line switch, obviously, belongs to Chromium, and so to all its derivative browsers, like Chrome itself. Therefore, you can move Chrome’s User Data folder to any location. After moving the folder itself, you just have to pass the new location via the --user-data-dir command line switch, as explained in Chromium Docs:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir=D:\Stuff\ChromeUserData
This finding is also useful because it shows that the whole User Data folder can ba copied to a different computer.
I found a possible Chromium bug, however, when moving User Data to my D:\ drive. When a notification pops-up, clicking it will open another Chrome window, and this new window will point to the original User Data location. Which means native notifications are unusable.
As Chrome’s adoption of Manifest V3 approaches, I’ve been trying Brave more and more, even in my Android. Using it for work had me in trouble though, since unlike Firefox, it has no native support to PKCS#11 USB tokens.
After trying a few things, I gave up. But a few minutes ago I stumbled upon a website which I’ve seen before, probably when setting up Chrome, and to my surprise it worked for my Linux Mint. He uses the same SafeNet eToken 5110 I’ve got here.
modutil -dbdir sql:.pki/nssdb/ -add "eToken" -libfile /usr/lib/libeTPkcs11.so
I don’t know if it matters, but I ran the command above before installing Brave itself.
As my SSD gets more and more stuffed, I’m searching for ways to remove the cruft from it. It’s a Windows 10 installation from 2018, which I have a feeling that it needs a fresh formatted install. But since I cannot afford that now, I just keep going.
Cleaning the temp folder manually is a cumbersome chore and also takes a lot of time. The batch script below, in the other hand, deletes all the files instantly:
echo Cleaning temp...
del /s /f /q %temp%\*
for /f %%f in ('dir /ad /b %temp%\') do rd /s /q %temp%\%%f
pause
A double click on the clean.bat file now can be done at any time, in no time.
Today I completely wiped away Pinia from a large Vue codebase at work. It was an immense effort, but I’m so pissed I didn’t mind working overtime.
The main reason to use Pinia is that you can inspect the state in DevTools – an idea taken from React –, but guess what. The extension only exists for Chrome now, and the current old Firefox version is broken. It looks like a project driven by amateurs, just like the horrible VSCode extension. And I’m not alone on this.
For the global stores, I’m simple using a reactive object, with functions and computed values inside – that’s what Pinia does anyway. I found this by digging into its source code. I also found that a computed inside a reactive makes the .value unnecessary, which is a merit of Vue’s reactivity system, which I still believe to be the best out there.
const state = reactive({
loading: false,
name: '',
foo: computed(() => state.name + '.'),
doAction(): {
console.info('Hello');
},
});
I really regret choosing Vue back in the day for this project. I should’ve choosen good ol’ React, because despite its flaws, it’s dependable.
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);
},
},
});