Skip to content
This repository has been archived by the owner on Feb 24, 2024. It is now read-only.

Feat/multiple projects support #293

Open
wants to merge 30 commits into
base: production
Choose a base branch
from
Open

Conversation

yehee
Copy link
Collaborator

@yehee yehee commented Apr 6, 2021

Motivation

  • Support multiple projects and add a sidebar on Customize page to ease navigation

Notable changes

  • {force: true} option for Cypress testing
  • Create Footer component
  • Delete BCP47Tag component
  • Merge/replace addManualEntryDictionaryToProject, updateManualEntryDictionaryToProject with putDirectEntry
  • Add project: number parameter as the project ID of interest to related methods
  • LandingPage logic:
    • Create a new project data as part of setLanguage: calls putProjectData that updates existing record if valid project ID is provided; creates a new record otherwise.
    • putProjectData returns the project ID which was created/modified
    • If user uploads a new file either by uploading from local or importing from Google Sheets, then setLanguage is called
      • If no language is selected just yet, use placeholder value i.e. Unknown Language
  • CustomisePage logic:
    • Created a sidebar which allows user to navigate between projects or create a new empty one
    • By default, the first project on the list is selected/displayed when the page loads
    • A placeholder to indicate no project selected (no project in progress)
  • Add dictionaryName attribute to RelevantKmpOptions
  • Move KMPJsonFileLanguage, StoredProjectData, StoredWordList to @common/types
  • importProjectData, exportProjectData now imports/exports a list of project data (used to be a single record)
  • DB schema for files now ++id, name, wordlist, size, project and KMPFileData now ++id, package, project where project is the foreign key to projectData.id
  • Current DB version: 8
  • No longer referencing PACKAGE_ID

Resolves #231, #188

@vercel
Copy link

vercel bot commented Apr 6, 2021

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/eddieantonio/predictive-text-studio/7gEECp9fUN72a11CSXrbX6D3CeAp
✅ Preview: https://predictive-text-studio-git-feat-multiple-projects-eddieantonio.vercel.app

@yehee yehee linked an issue Apr 6, 2021 that may be closed by this pull request
@yehee
Copy link
Collaborator Author

yehee commented Apr 12, 2021

@eddieantonio There are still work to do for this PR, but I noticed that some of the cypress test scenarios are failing because "the center of this element is hidden from view":
Screen Shot 2021-04-12 at 10 01 50 AM.

I wasn't sure if others are having similar issues, and they suggest to add { force: true } option as a workaround but just wanted to hear what you think!

@eddieantonio
Copy link
Owner

I wasn't sure if others are having similar issues, and they suggest to add { force: true } option as a workaround but just wanted to hear what you think!

In general, adding a workaround like {force: true} is not the greatest thing 😄 , but it's an acceptable case of incurring technical debt. It happens ¯\_(ツ)_/¯

This kind of thing should be fixed, but it's probably not a big deal; it may be a symptom of greater problems, but that's unclear to me at this point. As long as there's a comment explaining why the workaround was made, and maybe a // TODO: do not use force comment added on there too, it's fine!

@yehee
Copy link
Collaborator Author

yehee commented Apr 21, 2021

I should be able to start working on this PR next week as soon as I'm done with my finals 😞 . Any feedback or suggestions would be highly appreciated in the meantime!

@eddieantonio
Copy link
Owner

I should be able to start working on this PR next week as soon as I'm done with my finals 😞 . Any feedback or suggestions would be highly appreciated in the meantime!

@yehee: you are not obligated to complete this PR. I will give feedback in case you want to finish it.

src/app/pages/Customize.svelte Outdated Show resolved Hide resolved
src/app/pages/Customize.svelte Outdated Show resolved Hide resolved
src/app/pages/Customize.svelte Outdated Show resolved Hide resolved
<div class="customize__sidebar">
{#each projects as project}
<div class="customize__sidebar--project" class:selected={project.id === id} on:click={() => id = project.id}>
{(project.dictionaryName || "?").substring(0, 1)}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tl;dr: .substring(0,1)will break for many languages.

There's no good solution for this, but .substring(0,1) is, unfortunately, not good to get the first "letter" of the dictionary name. You want the first extended grapheme cluster of the name, and there's no easy way to do that in vanilla JavaScript at the moment (aside from dragging in a dependency just for this one task).

Also, because JavaScript chooses a rather annoying way of representing Unicode, .substring(0, 1) might actually return a broken character: an unpaired low surrogate. You can replicate this by getting the first "character" of the 💩 emoji:

> "💩".substring(0, 1)
'�'

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this thread on StackOverflow that might be an alternative to .substring(0,1): [...s][0] which will give us the first "character" of s assuming s is not empty.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the ol' Array.from(s)[0] trick works here to get the first code point. Unfortunately for us, the first code point is not necessarily the first graphem cluster, which Matthias Bynens points out in the accepted answer.

Try this:

> s = ("고추장").normalize("NFD")
'고추장'
> console.log(Array.from(s))[0])

Haha, again, this is a very tricky problem to solve in general, for all languages! 😅

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohh that's very interesting... Thanks a lot I'll update the code accordingly!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason we're going with NFD option for unicode normalization?

Copy link
Owner

@eddieantonio eddieantonio May 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha, I would always choose NFC. Unless you think "ᄀ" is the correct first letter for "고추장" (I don't know Korean, I just like spicy food).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense! I was wondering about that :) Will make the change accordingly!

src/app/pages/Customize.svelte Outdated Show resolved Hide resolved
@yehee yehee requested a review from eddieantonio May 2, 2021 00:58
@yehee yehee marked this pull request as ready for review May 2, 2021 00:58
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor the file handling to re-use business logic Mulitple project support
3 participants