Fix and enhance comment editor monospace toggle

[silverwind]

Fixes: #36175

1. Correctly apply setting on textareas spawned by comment edit
2. When changing the setting, apply it to all textareas on the current page

[silverwind]

I think this could be expanded to also apply the setting in other open tabs by leveraging the storage event:

https://developer.mozilla.org/en-US/docs/Web/API/Window/storage_event

I guess a small storage helper module is needed to abstract this out of the file and be useful for all localStorage-backed variables.

[silverwind]

I've added the bare minimum to get the setting working across tabs too. There's probably an opportunity to abstract into some localStorage module suitable for more similar localStorage-backed settings, but I'm not totally certain how to design it.

[silverwind]

web_src/js/modules/storage.ts is now contains minimal localStorage wrapper functions and I've used them everywhere where we previously used localStorage directly (except inline scripts, but that's another topic to be solved via web components). This is in preparation so that these settings can be synced to the server in the future.

[wxiaoguang]

To make code maintainable: b32c75f

[silverwind]

Instead of all these get<Type> functions, we could let TypeScript handle it for us. a is string and b is number, it works like magic.

[wxiaoguang]

Instead of all these get<Type> functions, we could let TypeScript handle it for us. a is string and b is number, it works like magic.

It doesn't work. Or, you can make changes as your proposal.

[wxiaoguang]

a is string and b is number, it works like magic.

It won't work like magic because our code needs to handle string parsing (not simply use the local storage value as-is).

I believe the current design is good enough, easy to use and error-proof. So I think we can get it merged.

[silverwind]

Hmm fine, I still think Typescript could be leveraged and that functions like GetString have no right to exist in a sound type system.

[silverwind]

Assuming we will sync to server later, I would not name it localUserSettings but userSettings.

[wxiaoguang]

Assuming we will sync to server later, I would not name it localUserSettings but userSettings.

I believe no at the moment. Because when that time reaches, the design will be quite different.

And since there is TypeScript type checking, it is easier to rewrite in the future.

[silverwind]

Assuming we will sync to server later, I would not name it localUserSettings but userSettings.

I believe no at the moment. Because when that time reaches, the design will be quite different.

And since there is TypeScript type checking, it is easier to rewrite in the future.

I guess it's actually ok because these settings are always kept local currently, so we can later rename the var to fit.

[silverwind]

lgtm