Don't store checkbox instances in NotificationGrid

[askvortsov1]

Refs #1821 #2144

Changes proposed in this pull request:

• Don't store checkbox instances in NotificationGrid
• Use props for Checkbox/Switch loading state instead of attribute so it can be passed in / modified

Reviewers should focus on:

• The code in view is very repetetive. Can we somehow put the key into a variable?
• I don't like that preferenceSaver is directly changing the component's props like that. But I also don't think it's a priority (we're not storing an instance of the component), and I don't know exactly what to do with it (we could have a register of all the fields / preferences as an extensible method, create an array of loadingState in init of SettingsPage, but that would still require extensions that add preferences to include a reference to that loadingState, breaking their loading indicators)

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).

[clarkwinkelmann]

I'm fine with this approach.

I do think we should also take care of your other remarks at the same time.

In particular the preferenceSaver thing WILL need change anyway to work with Mithril 2. We will need accompanying PRs for the extensions that use this method.

[franzliedke]

In particular the preferenceSaver thing WILL need change anyway to work with Mithril 2.

@clarkwinkelmann Can you expand on that? It seems to contradict what @askvortsov1 said in the PR description:

I don't like that preferenceSaver is directly changing the component's props like that. But I also don't think it's a priority (we're not storing an instance of the component), ...

I'm probably just misunderstanding something, though.

[franzliedke]

Looks good, but Clark's comments need to be taken care of.

(It's sad that the checkboxes don't completely encapsulate their loading state, but that's been a problem before, so it's not relevant here...)

[clarkwinkelmann]

The component variable is a component instance, which we won't be able to pass once we stop using component instances.

Currently the way that instance is obtained is through the second parameter of onchange. I'm not sure what Mithril did in the latest versions but I doubt the component instance is still passed https://github.com/flarum/core/blob/638d6d79ca25adde174ce755a05b80cb26d0f5ee/js/src/forum/components/SettingsPage.js#L142

An alternative could be to pass the props object, but then it requires saving an instance of the props object. So I would recommend storing an attribute for the loading state of each individual checkbox.

[askvortsov1]

Argh that's a good point, I hadn't thought of that... Considering that pretty much every preference is updated on change, perhaps preferenceLoadingState could be separated out as a property of the current user along with the preferences themselves?

[askvortsov1]

So I would recommend storing an attribute for the loading state of each individual checkbox.

I've been thinking about this, but can't come up with a good place to store the preference loading states:

1. We could do it individually as streams, and provide those to the preference saver
2. We could store it individually and have each component be in charge of changing its own loading state. We should probably also then separate out the preferenceSaver into a helper/util. We could also bind the preferenceSaver to the component so the preferenceSaver can edit this.loading
3. We could store it in the Settings page via an extensible itemlist of keys (all initialized to false), and have the preference saver manipulate it from there.
4. We could store it with the User model.

My favorite here is probably 2, but I would also be alright with 3. Not a fan of 1 or 4.

[clarkwinkelmann]

@askvortsov1 yes my thought was option 2.

We should probably also then separate out the preferenceSaver into a helper/util

I don't think that's necessary. It's already a wrapper around the very apt this.user.savePreferences() function. I don't think another helper method is necessary. Let's leave extensions the task of managing their loading states. They can just copy what we did in core here anyway.

I'd suggest applying my two proposed code samples from the in-code comments and then I'm ok with the PR.

[dsevillamartin]

Breaking changes:

• NotificationGrid inputs no longer exists
• Checkbox loading class property is now a loading component prop

Changes have been made