2021-06-20 03:45:37 +02:00
|
|
|
import i18n from '../../i18n/index'
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
import { MAIN_PROFILE_ID, IpcChannels, SyncEvents } from '../../../constants'
|
|
|
|
import { DBSettingHandlers } from '../../../datastores/handlers/index'
|
2020-02-16 19:30:00 +01:00
|
|
|
|
2021-06-11 02:59:59 +02:00
|
|
|
/*
|
|
|
|
* Due to the complexity of the settings module in FreeTube, a more
|
|
|
|
* in-depth explanation for adding new settings is required.
|
2021-06-06 07:32:41 +02:00
|
|
|
*
|
2021-06-11 02:59:59 +02:00
|
|
|
* The explanation will be written with the assumption that
|
|
|
|
* the reader knows how Vuex works.
|
2021-06-06 07:32:41 +02:00
|
|
|
*
|
2021-06-11 02:59:59 +02:00
|
|
|
* And no, there's no need to read the entire wall of text.
|
|
|
|
* We'll direct you where you need to go as we walk you through it.
|
|
|
|
* Additionally, the text actually looks bigger than it truly is.
|
|
|
|
* Each line has, at most, 72 characters.
|
2021-06-06 07:32:41 +02:00
|
|
|
*
|
2021-06-11 02:59:59 +02:00
|
|
|
****
|
|
|
|
* Introduction
|
2021-06-06 07:32:41 +02:00
|
|
|
*
|
2021-06-11 02:59:59 +02:00
|
|
|
* You can add a new setting in three different methods.
|
2021-06-06 07:32:41 +02:00
|
|
|
*
|
2021-06-11 02:59:59 +02:00
|
|
|
* The first two methods benefit from the auto-generation of
|
|
|
|
* a getter, a mutation and a few actions related to the setting.
|
|
|
|
* Those two methods should be preferred whenever possible:
|
|
|
|
* - `state`
|
|
|
|
* - `stateWithSideEffects`
|
|
|
|
*
|
|
|
|
* The last one DOES NOT feature any kind of auto-generation and should
|
|
|
|
* only be used in scenarios that don't fall under the other 2 options:
|
|
|
|
* - `customState`
|
|
|
|
*
|
|
|
|
****
|
|
|
|
* ASIDE:
|
|
|
|
* The aforementioned "side effects" cover a large area
|
|
|
|
* of interactions with other modules
|
|
|
|
* A good example would be a setting that utilizes the Electron API
|
|
|
|
* when its value changes.
|
|
|
|
*
|
|
|
|
****
|
|
|
|
* First and foremost, you have to understand what type of setting
|
|
|
|
* you intend to add to the app.
|
|
|
|
*
|
|
|
|
* You'll have to select one of these three scenarios:
|
|
|
|
*
|
|
|
|
* 1) You just want to add a simple setting that does not actively
|
|
|
|
* interact with the Electron API, `localStorage` or
|
|
|
|
* other parts outside of the settings module.
|
|
|
|
* -> Please consult the `state` section.
|
|
|
|
*
|
|
|
|
* 2) You want to add a more complex setting that interacts
|
|
|
|
* with other parts of the app and tech stack.
|
|
|
|
* -> Please consult the `state` and `stateWithSideEffects` sections.
|
|
|
|
*
|
|
|
|
* 3) You want to add a completely custom state based setting
|
|
|
|
* that does not work like the usual settings.
|
|
|
|
* -> Please consult the `state` and `customState` sections.
|
|
|
|
*
|
|
|
|
****
|
|
|
|
* `state`
|
|
|
|
* This object contains settings that have NO SIDE EFFECTS.
|
|
|
|
*
|
|
|
|
* A getter, mutation and an action function is auto-generated
|
|
|
|
* for every setting present in the `state` object.
|
|
|
|
* They have the following format (exemplified with setting 'example'):
|
|
|
|
*
|
|
|
|
* Getter: `getExample` (gets the value from current state)
|
|
|
|
* Mutation:
|
|
|
|
* `setExample`
|
|
|
|
* (takes a value
|
|
|
|
* and uses it to update the current state)
|
|
|
|
* Action:
|
|
|
|
* `updateExample`
|
|
|
|
* (takes a value,
|
|
|
|
* saves it to the database
|
|
|
|
* and calls `setExample` with it)
|
|
|
|
*
|
|
|
|
***
|
|
|
|
* `stateWithSideEffects`
|
|
|
|
* This object contains settings that have SIDE EFFECTS.
|
|
|
|
*
|
|
|
|
* Each one of these settings must specify an object
|
|
|
|
* with the following properties:
|
|
|
|
* - `defaultValue`
|
|
|
|
* (which is the value you would put down if
|
|
|
|
* you were to add the setting to the regular `state` object)
|
|
|
|
*
|
|
|
|
* - `sideEffectsHandler`
|
|
|
|
* (which should essentially be a callback of type
|
|
|
|
* `(store, value) => void`
|
|
|
|
* that deals with the side effects for that setting)
|
|
|
|
*
|
|
|
|
* NOTE: Example implementations of such settings can be found
|
|
|
|
* in the `stateWithSideEffects` object in case
|
|
|
|
* the explanation isn't clear enough.
|
|
|
|
*
|
|
|
|
* All functions auto-generated for settings in `state`
|
|
|
|
* (if you haven't read the `state` section, do it now),
|
|
|
|
* are also auto-generated for settings in `stateWithSideEffects`,
|
|
|
|
* with a few key differences (exemplified with setting 'example'):
|
|
|
|
*
|
|
|
|
* - an additional action is auto-generated:
|
|
|
|
* - `triggerExampleSideEffects`
|
|
|
|
* (triggers the `sideEffectsHandler` for that setting;
|
|
|
|
* you'll most likely never call this directly)
|
|
|
|
*
|
|
|
|
* - the behavior of `updateExample` changes a bit:
|
|
|
|
* - `updateExample`
|
|
|
|
* (saves value to the database,
|
|
|
|
* calls `triggerExampleSideEffects` and calls `setExample`)
|
|
|
|
*
|
|
|
|
***
|
|
|
|
* `customState`
|
|
|
|
* This object contains settings that
|
|
|
|
* don't linearly fall under the other two options.
|
|
|
|
*
|
|
|
|
* No auto-generation of any kind is performed
|
|
|
|
* when a setting is added to `customState`
|
|
|
|
*
|
|
|
|
* You must manually add any getters, mutations and actions to
|
|
|
|
* `customGetters`, `customMutations` and `customActions` respectively
|
|
|
|
* that you find appropriate for that setting.
|
|
|
|
*
|
|
|
|
* NOTE:
|
|
|
|
* When adding a setting to the `customState`,
|
|
|
|
* additional consultation with the FreeTube team is preferred
|
|
|
|
* to evaluate if it is truly necessary
|
|
|
|
* and to ensure that the implementation works as intended.
|
|
|
|
*
|
|
|
|
* A good example of a setting of this type would be `usingElectron`.
|
|
|
|
* This setting doesn't need to be persisted in the database
|
|
|
|
* and it doesn't change over time.
|
|
|
|
* Therefore, it needs a getter (which we add to `customGetters`), but
|
|
|
|
* has no need for a mutation or any sort of action.
|
|
|
|
*
|
|
|
|
****
|
|
|
|
* ENDING NOTES
|
|
|
|
*
|
|
|
|
* Only two more things that need mentioning.
|
|
|
|
*
|
|
|
|
* 1) It's perfectly fine to add extra functionality
|
|
|
|
* to the `customGetters`, `customMutations` and `customActions`,
|
|
|
|
* whether it's related to a setting or just serving as
|
|
|
|
* standalone functionality for the module
|
|
|
|
* (e.g. `grabUserSettings` (standalone action))
|
|
|
|
*
|
|
|
|
* 2) It's also possible to OVERRIDE auto-generated functionality by
|
|
|
|
* adding functions with the same identifier to
|
|
|
|
* the respective `custom__` object,
|
|
|
|
* but you must have an acceptable reason for doing so.
|
|
|
|
****
|
2021-06-06 07:32:41 +02:00
|
|
|
*/
|
2021-06-11 02:59:59 +02:00
|
|
|
|
|
|
|
// HELPERS
|
|
|
|
const capitalize = str => str.replace(/^\w/, c => c.toUpperCase())
|
|
|
|
const defaultGetterId = settingId => 'get' + capitalize(settingId)
|
|
|
|
const defaultMutationId = settingId => 'set' + capitalize(settingId)
|
|
|
|
const defaultUpdaterId = settingId => 'update' + capitalize(settingId)
|
|
|
|
const defaultSideEffectsTriggerId = settingId =>
|
|
|
|
'trigger' + capitalize(settingId) + 'SideEffects'
|
|
|
|
/*****/
|
|
|
|
|
2020-02-16 19:30:00 +01:00
|
|
|
const state = {
|
2021-06-11 04:56:03 +02:00
|
|
|
autoplayPlaylists: true,
|
|
|
|
autoplayVideos: true,
|
2020-03-01 04:37:02 +01:00
|
|
|
backendFallback: true,
|
2020-02-19 04:31:10 +01:00
|
|
|
backendPreference: 'local',
|
2020-03-01 04:37:02 +01:00
|
|
|
barColor: false,
|
2021-06-11 04:56:03 +02:00
|
|
|
checkForBlogPosts: true,
|
|
|
|
checkForUpdates: true,
|
2022-03-05 09:09:32 +01:00
|
|
|
baseTheme: 'dark',
|
|
|
|
mainColor: 'Red',
|
|
|
|
secColor: 'Blue',
|
2021-06-11 04:56:03 +02:00
|
|
|
defaultCaptionSettings: '{}',
|
2021-03-06 17:25:50 +01:00
|
|
|
defaultInterval: 5,
|
2020-03-01 04:37:02 +01:00
|
|
|
defaultPlayback: 1,
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
defaultProfile: MAIN_PROFILE_ID,
|
2020-05-28 04:48:41 +02:00
|
|
|
defaultQuality: '720',
|
2021-08-05 22:17:01 +02:00
|
|
|
defaultSkipInterval: 5,
|
2021-06-11 04:56:03 +02:00
|
|
|
defaultTheatreMode: false,
|
|
|
|
defaultVideoFormat: 'dash',
|
2020-10-07 15:57:22 +02:00
|
|
|
disableSmoothScrolling: false,
|
2021-06-11 04:56:03 +02:00
|
|
|
displayVideoPlayButton: true,
|
|
|
|
enableSearchSuggestions: true,
|
|
|
|
enableSubtitles: true,
|
2021-09-17 01:03:25 +02:00
|
|
|
externalLinkHandling: '',
|
2021-06-13 17:31:43 +02:00
|
|
|
externalPlayer: '',
|
|
|
|
externalPlayerExecutable: '',
|
|
|
|
externalPlayerIgnoreWarnings: false,
|
|
|
|
externalPlayerCustomArgs: '',
|
2022-03-05 09:09:32 +01:00
|
|
|
expandSideBar: false,
|
2021-06-11 04:56:03 +02:00
|
|
|
forceLocalBackendForLegacy: false,
|
|
|
|
hideActiveSubscriptions: false,
|
2020-10-06 04:27:32 +02:00
|
|
|
hideChannelSubscriptions: false,
|
|
|
|
hideCommentLikes: false,
|
2021-06-11 04:56:03 +02:00
|
|
|
hideLiveChat: false,
|
|
|
|
hidePlaylists: false,
|
|
|
|
hidePopularVideos: false,
|
2020-10-06 04:27:32 +02:00
|
|
|
hideRecommendedVideos: false,
|
|
|
|
hideTrendingVideos: false,
|
2021-06-11 04:56:03 +02:00
|
|
|
hideVideoLikesAndDislikes: false,
|
|
|
|
hideVideoViews: false,
|
|
|
|
hideWatchedSubs: false,
|
2021-10-05 22:16:47 +02:00
|
|
|
hideLabelsSideBar: false,
|
2021-06-11 04:56:03 +02:00
|
|
|
landingPage: 'subscriptions',
|
|
|
|
listType: 'grid',
|
|
|
|
playNextVideo: false,
|
|
|
|
proxyHostname: '127.0.0.1',
|
|
|
|
proxyPort: '9050',
|
|
|
|
proxyProtocol: 'socks5',
|
|
|
|
proxyVideos: false,
|
|
|
|
region: 'US',
|
|
|
|
rememberHistory: true,
|
|
|
|
removeVideoMetaFiles: true,
|
|
|
|
saveWatchedProgress: true,
|
2021-05-29 20:35:28 +02:00
|
|
|
sponsorBlockShowSkippedToast: true,
|
2021-06-11 04:56:03 +02:00
|
|
|
sponsorBlockUrl: 'https://sponsor.ajay.app',
|
|
|
|
thumbnailPreference: '',
|
|
|
|
useProxy: false,
|
|
|
|
useRssFeeds: false,
|
|
|
|
useSponsorBlock: false,
|
2021-11-24 22:52:56 +01:00
|
|
|
videoVolumeMouseScroll: false,
|
2022-01-30 18:49:16 +01:00
|
|
|
videoPlaybackRateMouseScroll: false,
|
|
|
|
downloadFolderPath: ''
|
2020-02-16 19:30:00 +01:00
|
|
|
}
|
|
|
|
|
2021-06-11 02:59:59 +02:00
|
|
|
const stateWithSideEffects = {
|
2021-06-20 03:45:37 +02:00
|
|
|
currentLocale: {
|
|
|
|
defaultValue: 'en-US',
|
|
|
|
sideEffectsHandler: async function ({ dispatch }, value) {
|
|
|
|
const defaultLocale = 'en-US'
|
|
|
|
|
|
|
|
let targetLocale = value
|
|
|
|
if (value === 'system') {
|
|
|
|
const systemLocale = await dispatch('getSystemLocale')
|
|
|
|
|
|
|
|
targetLocale = Object.keys(i18n.messages).find((locale) => {
|
|
|
|
const localeName = locale.replace('-', '_')
|
|
|
|
return localeName.includes(systemLocale.replace('-', '_'))
|
|
|
|
})
|
|
|
|
|
|
|
|
// Go back to default value if locale is unavailable
|
|
|
|
if (!targetLocale) {
|
|
|
|
targetLocale = defaultLocale
|
|
|
|
// Translating this string isn't necessary
|
|
|
|
// because the user will always see it in the default locale
|
|
|
|
// (in this case, English (US))
|
|
|
|
dispatch('showToast',
|
|
|
|
{ message: `Locale not found, defaulting to ${defaultLocale}` }
|
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
i18n.locale = targetLocale
|
|
|
|
dispatch('getRegionData', {
|
|
|
|
isDev: process.env.NODE_ENV === 'development',
|
|
|
|
locale: targetLocale
|
|
|
|
})
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2021-07-03 03:55:56 +02:00
|
|
|
defaultInvidiousInstance: {
|
|
|
|
defaultValue: '',
|
|
|
|
sideEffectsHandler: ({ commit, getters }, value) => {
|
|
|
|
if (value !== '' && getters.getCurrentInvidiousInstance !== value) {
|
|
|
|
commit('setCurrentInvidiousInstance', value)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2021-06-11 03:33:36 +02:00
|
|
|
defaultVolume: {
|
|
|
|
defaultValue: 1,
|
|
|
|
sideEffectsHandler: (_, value) => {
|
|
|
|
sessionStorage.setItem('volume', value)
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2021-06-11 03:22:59 +02:00
|
|
|
uiScale: {
|
|
|
|
defaultValue: 100,
|
|
|
|
sideEffectsHandler: ({ state: { usingElectron } }, value) => {
|
|
|
|
if (usingElectron) {
|
|
|
|
const { webFrame } = require('electron')
|
|
|
|
webFrame.setZoomFactor(value / 100)
|
|
|
|
}
|
|
|
|
}
|
2021-06-06 07:32:41 +02:00
|
|
|
}
|
|
|
|
}
|
2021-05-29 20:35:28 +02:00
|
|
|
|
2021-06-11 02:59:59 +02:00
|
|
|
const customState = {
|
|
|
|
usingElectron: (window?.process?.type === 'renderer')
|
|
|
|
}
|
2021-05-16 22:01:24 +02:00
|
|
|
|
2021-06-11 02:59:59 +02:00
|
|
|
const customGetters = {
|
2021-06-06 07:32:41 +02:00
|
|
|
getUsingElectron: (state) => state.usingElectron
|
2021-06-11 02:59:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
const customMutations = {}
|
|
|
|
|
|
|
|
/**********/
|
|
|
|
/*
|
|
|
|
* DO NOT TOUCH THIS SECTION
|
|
|
|
* If you wanna add to custom data or logic to the module,
|
|
|
|
* do so in the aproppriate `custom_` variable
|
|
|
|
*
|
|
|
|
* Some of the custom actions below use these properties, so I'll be
|
|
|
|
* adding them here instead of further down for clarity's sake
|
|
|
|
*/
|
|
|
|
Object.assign(customState, {
|
|
|
|
settingsWithSideEffects: Object.keys(stateWithSideEffects)
|
2021-06-06 07:32:41 +02:00
|
|
|
})
|
2021-05-16 22:01:24 +02:00
|
|
|
|
2021-06-11 02:59:59 +02:00
|
|
|
Object.assign(customGetters, {
|
|
|
|
settingHasSideEffects: (state) => {
|
|
|
|
return (id) => state.settingsWithSideEffects.includes(id)
|
|
|
|
}
|
|
|
|
})
|
|
|
|
/**********/
|
2020-02-16 19:30:00 +01:00
|
|
|
|
2021-06-11 02:59:59 +02:00
|
|
|
const customActions = {
|
2021-06-17 05:16:52 +02:00
|
|
|
grabUserSettings: async ({ commit, dispatch, getters }) => {
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
try {
|
|
|
|
const userSettings = await DBSettingHandlers.find()
|
|
|
|
for (const setting of userSettings) {
|
|
|
|
const { _id, value } = setting
|
|
|
|
if (getters.settingHasSideEffects(_id)) {
|
|
|
|
dispatch(defaultSideEffectsTriggerId(_id), value)
|
|
|
|
}
|
2021-06-06 19:53:18 +02:00
|
|
|
|
2022-04-10 23:15:41 +02:00
|
|
|
if (Object.keys(mutations).includes(defaultMutationId(_id))) {
|
|
|
|
commit(defaultMutationId(_id), value)
|
|
|
|
}
|
2021-06-17 05:16:52 +02:00
|
|
|
}
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
} catch (errMessage) {
|
|
|
|
console.error(errMessage)
|
2021-06-17 05:16:52 +02:00
|
|
|
}
|
2021-06-09 06:57:35 +02:00
|
|
|
},
|
|
|
|
|
2021-06-20 20:34:11 +02:00
|
|
|
// Should be a root action, but we'll tolerate
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
setupListenersToSyncWindows: ({ commit, dispatch, getters }) => {
|
2021-06-20 20:34:11 +02:00
|
|
|
// Already known to be Electron, no need to check
|
|
|
|
const { ipcRenderer } = require('electron')
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
|
|
|
|
ipcRenderer.on(IpcChannels.SYNC_SETTINGS, (_, { event, data }) => {
|
|
|
|
switch (event) {
|
|
|
|
case SyncEvents.GENERAL.UPSERT:
|
2021-06-20 20:34:11 +02:00
|
|
|
if (getters.settingHasSideEffects(data._id)) {
|
|
|
|
dispatch(defaultSideEffectsTriggerId(data._id), data.value)
|
|
|
|
}
|
|
|
|
|
|
|
|
commit(defaultMutationId(data._id), data.value)
|
|
|
|
break
|
|
|
|
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
default:
|
|
|
|
console.error('settings: invalid sync event received')
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
ipcRenderer.on(IpcChannels.SYNC_HISTORY, (_, { event, data }) => {
|
|
|
|
switch (event) {
|
|
|
|
case SyncEvents.GENERAL.UPSERT:
|
|
|
|
commit('upsertToHistoryCache', data)
|
|
|
|
break
|
|
|
|
|
|
|
|
case SyncEvents.HISTORY.UPDATE_WATCH_PROGRESS:
|
|
|
|
commit('updateRecordWatchProgressInHistoryCache', data)
|
|
|
|
break
|
|
|
|
|
|
|
|
case SyncEvents.GENERAL.DELETE:
|
|
|
|
commit('removeFromHistoryCacheById', data)
|
|
|
|
break
|
|
|
|
|
|
|
|
case SyncEvents.GENERAL.DELETE_ALL:
|
|
|
|
commit('setHistoryCache', [])
|
|
|
|
break
|
|
|
|
|
|
|
|
default:
|
|
|
|
console.error('history: invalid sync event received')
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
ipcRenderer.on(IpcChannels.SYNC_PROFILES, (_, { event, data }) => {
|
|
|
|
switch (event) {
|
|
|
|
case SyncEvents.GENERAL.CREATE:
|
|
|
|
commit('addProfileToList', data)
|
|
|
|
break
|
|
|
|
|
|
|
|
case SyncEvents.GENERAL.UPSERT:
|
|
|
|
commit('upsertProfileToList', data)
|
2021-06-20 20:34:11 +02:00
|
|
|
break
|
|
|
|
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
case SyncEvents.GENERAL.DELETE:
|
|
|
|
commit('removeProfileFromList', data)
|
|
|
|
break
|
|
|
|
|
|
|
|
default:
|
|
|
|
console.error('profiles: invalid sync event received')
|
|
|
|
}
|
|
|
|
})
|
|
|
|
|
|
|
|
ipcRenderer.on(IpcChannels.SYNC_PLAYLISTS, (_, { event, data }) => {
|
|
|
|
switch (event) {
|
|
|
|
case SyncEvents.PLAYLISTS.UPSERT_VIDEO:
|
|
|
|
commit('addVideo', data)
|
2021-06-20 20:34:11 +02:00
|
|
|
break
|
|
|
|
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
case SyncEvents.PLAYLISTS.DELETE_VIDEO:
|
|
|
|
commit('removeVideo', data)
|
2021-06-20 20:34:11 +02:00
|
|
|
break
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
|
|
|
|
default:
|
|
|
|
console.error('playlists: invalid sync event received')
|
2021-06-20 20:34:11 +02:00
|
|
|
}
|
|
|
|
})
|
2020-02-16 19:30:00 +01:00
|
|
|
}
|
2021-06-11 02:59:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/**********************/
|
|
|
|
/*
|
|
|
|
* DO NOT TOUCH ANYTHING BELOW
|
|
|
|
* (unless you plan to change the architecture of this module)
|
|
|
|
*/
|
|
|
|
|
|
|
|
const getters = {}
|
|
|
|
const mutations = {}
|
|
|
|
const actions = {}
|
|
|
|
|
|
|
|
// Add settings that contain side effects to the state
|
|
|
|
Object.assign(
|
|
|
|
state,
|
|
|
|
Object.fromEntries(
|
|
|
|
Object.keys(stateWithSideEffects).map(
|
|
|
|
(key) => [
|
|
|
|
key,
|
|
|
|
stateWithSideEffects[key].defaultValue
|
|
|
|
]
|
|
|
|
)
|
|
|
|
)
|
|
|
|
)
|
|
|
|
|
|
|
|
// Build default getters, mutations and actions for every setting id
|
|
|
|
for (const settingId of Object.keys(state)) {
|
|
|
|
const getterId = defaultGetterId(settingId)
|
|
|
|
const mutationId = defaultMutationId(settingId)
|
|
|
|
const updaterId = defaultUpdaterId(settingId)
|
|
|
|
const triggerId = defaultSideEffectsTriggerId(settingId)
|
|
|
|
|
|
|
|
getters[getterId] = (state) => state[settingId]
|
|
|
|
mutations[mutationId] = (state, value) => { state[settingId] = value }
|
|
|
|
|
|
|
|
// If setting has side effects, generate action to handle them
|
|
|
|
if (Object.keys(stateWithSideEffects).includes(settingId)) {
|
|
|
|
actions[triggerId] = stateWithSideEffects[settingId].sideEffectsHandler
|
|
|
|
}
|
|
|
|
|
2021-06-17 05:16:52 +02:00
|
|
|
actions[updaterId] = async ({ commit, dispatch, getters }, value) => {
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
try {
|
|
|
|
await DBSettingHandlers.upsert(settingId, value)
|
2021-06-11 02:59:59 +02:00
|
|
|
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
if (getters.settingHasSideEffects(settingId)) {
|
|
|
|
dispatch(triggerId, value)
|
|
|
|
}
|
2021-06-11 02:59:59 +02:00
|
|
|
|
Store Revamp / Full database synchronization across windows (#1833)
* History: Refactor history module
* Profiles: Refactor profiles module
* IPC: Move channel ids to their own file and make them constants
* IPC: Replace single sync channel for one channel per sync type
* Everywhere: Replace default profile id magic strings with constant ref
* Profiles: Refactor `activeProfile` property from store
This commit makes it so that `activeProfile`'s getter returns
the entire profile, while the related update function only needs
the profile id (instead of the previously used array index)
to change the currently active profile.
This change was made due to inconsistency regarding the active profile
when creating new profiles.
If a new profile coincidentally landed in the current active profile's
array index after sorting, the app would mistakenly change to it
without any action from the user apart from the profile's creation.
Turning the profile id into the selector instead solves this issue.
* Revert "Store: Implement history synchronization between windows"
This reverts commit 99b61e617873412eb393d8f4dfccd8f8c172021f.
This is necessary for an upcoming improved implementation of the
history synchronization.
* History: Remove unused mutation
* Everywhere: Create abstract database handlers
The project now utilizes abstract handlers to fetch, modify
or otherwise manipulate data from the database.
This facilitates 3 aspects of the app, in addition of
making them future proof:
- Switching database libraries is now trivial
Since most of the app utilizes the abstract handlers, it's incredibly
easily to change to a different DB library.
Hypothetically, all that would need to be done is to simply replace the
the file containing the base handlers, while the rest of the app
would go unchanged.
- Syncing logic between Electron and web is now properly separated
There are now two distinct DB handling APIs: the Electron one and
the web one.
The app doesn't need to manually choose the API, because it's detected
which platform is being utilized on import.
- All Electron windows now share the same database instance
This provides a single source of truth, improving consistency
regarding data manipulation and windows synchronization.
As a sidenote, syncing implementation has been left as is
(web unimplemented; Electron only syncs settings, remaining
datastore syncing will be implemented in the upcoming commits).
* Electron/History: Implement history synchronization
* Profiles: Implement suplementary profile creation logic
* ft-profile-edit: Small fix on profile name missing display
* Electron/Profiles: Implement profile synchronization
* Electron/Playlists: Implement playlist synchronization
2021-12-15 19:42:24 +01:00
|
|
|
commit(mutationId, value)
|
|
|
|
} catch (errMessage) {
|
|
|
|
console.error(errMessage)
|
2021-06-17 05:16:52 +02:00
|
|
|
}
|
2021-06-11 02:59:59 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add all custom data/logic to their respective objects
|
|
|
|
Object.assign(state, customState)
|
|
|
|
Object.assign(getters, customGetters)
|
|
|
|
Object.assign(mutations, customMutations)
|
|
|
|
Object.assign(actions, customActions)
|
2020-02-16 19:30:00 +01:00
|
|
|
|
|
|
|
export default {
|
|
|
|
state,
|
|
|
|
getters,
|
|
|
|
actions,
|
|
|
|
mutations
|
|
|
|
}
|