You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the previous milestone a major new feature was added to the components palette in the form of the Flash and Card components. The composition of these components is meant to enable writers to use as many cards as they see fit, and features a "Remembered" and "Didn't Remember" answer structure. (See #38) These components, when used together form a Flashcard game session which currently features it's own localized state with useImmer. This works for now, until we want to persist that data, tie it a user's wallet, and store the learning progress of an individual user in a backend DB.
Right now, if you refresh the page your Flashcard game state is reset and none of your progress is saved. In the next milestone, the hope is to persist this data and attach it to an identifiable user. My initial off the cuff thoughts are that you'd use a DB of you're own liking (most likely relational so you can just grab a user and their data) and establish a Many-to-One relationship where you'll have Many users with their own data. Unless Kernel's intention is to make this data shareable or grouped between users (Many-to-Many relationship), this seems like the best path for now.
On the front end I recommend creating a globalized state for the user using something like react-ridge-state with useSWR to pull down user data and persist it in a browser session, thus replacing the initial state setup for useImmer in the Flash component. This will enable you to start the ground work for a flexible data fetching pattern in regards to UI state, and data state.
Expanding search
Search, built using LUNR, has 2 places it can be effected. The gatsby-config object for LUNR, and the search query method in the search module modules/search/index.js. In the latter you'll see that I'm handling fuzzy matching, wild cards, and field boosting in the tokenizer. It is recommended you tweak both locations to get desired results, given the gatsby-config will edit pre-build data, and the search index edits client-side query data.
The text was updated successfully, but these errors were encountered:
cc @andytudhope
Flashcards Next Steps with Data
In the previous milestone a major new feature was added to the components palette in the form of the
Flash
andCard
components. The composition of these components is meant to enable writers to use as many cards as they see fit, and features a "Remembered" and "Didn't Remember" answer structure. (See #38) These components, when used together form a Flashcard game session which currently features it's own localized state withuseImmer
. This works for now, until we want to persist that data, tie it a user's wallet, and store the learning progress of an individual user in a backend DB.Right now, if you refresh the page your Flashcard game state is reset and none of your progress is saved. In the next milestone, the hope is to persist this data and attach it to an identifiable user. My initial off the cuff thoughts are that you'd use a DB of you're own liking (most likely relational so you can just grab a user and their data) and establish a Many-to-One relationship where you'll have Many users with their own data. Unless Kernel's intention is to make this data shareable or grouped between users (Many-to-Many relationship), this seems like the best path for now.
On the front end I recommend creating a globalized state for the user using something like react-ridge-state with useSWR to pull down user data and persist it in a browser session, thus replacing the initial state setup for useImmer in the Flash component. This will enable you to start the ground work for a flexible data fetching pattern in regards to UI state, and data state.
Expanding search
Search, built using LUNR, has 2 places it can be effected. The gatsby-config object for LUNR, and the search query method in the search module
modules/search/index.js
. In the latter you'll see that I'm handling fuzzy matching, wild cards, and field boosting in the tokenizer. It is recommended you tweak both locations to get desired results, given the gatsby-config will edit pre-build data, and the search index edits client-side query data.The text was updated successfully, but these errors were encountered: