ExportProject actions/reducer/state

[imnasnainaec]

• Implement redux actions, reducer, and state for ExportProject
• Remove unnecessary layer in MergeDup reducer
• Organize reducers and states
• Split the frontend export project function into two parts: export to zip, download zip
  • At present, the export function is a placeholder and the download function does all the work
  • The functionality still needs to be split in the backend, and the frontend functions updated to match

---

This change is 

[johnthagen]

---

src/rootReducer.tsx, line 22 at r1 (raw file):

  localize: localizeReducer,

  //login

Super minor, but the convention I've seen most is to place one space after // before a comment if we want to try to stay consistent across all of our code bases.

[johnthagen]

---

src/backend/index.tsx, line 332 at r1 (raw file):

export async function exportLift(projectId?: string) {
  let projectIdToExport = projectId ? projectId : LocalStorage.getProjectId();
  // ToDo: Once the create and download functions are split in the backend,

Super minor, but I've usually seen it written TODO for what it's worth.

[johnthagen]

---

src/backend/index.tsx, line 331 at r1 (raw file):

// Tell the backend to create a LIFT file for the project
export async function exportLift(projectId?: string) {
  let projectIdToExport = projectId ? projectId : LocalStorage.getProjectId();

LocalStorage.getProjectId() returns "" if there is no project. Would it be more type safe if it returned undef so that we could check for if it exists? Not sure what would happen if you try to query for a blank project (probably a silent error to user)?

[johnthagen]

---

src/components/ProjectSettings/ProjectExport/ExportProjectActions.tsx, line 18 at r1 (raw file):

}

export function asyncExportProject(projectId?: string) {

These all take projectId?. What should happen if undef gets passed in here?

Is there anyway to ensure undef isn't passed in at a higher level and handled once to make the signatures on these functions tighter?

[johnthagen]

---

src/components/ProjectSettings/ProjectExport/ExportProjectReducer.tsx, line 10 at r1 (raw file):

export const defaultState: ExportProjectState = {
  projectId: "",

Another instance of a "" project ID. It's not clear to me what this means. Should it instead be projectId?: undef so we can handle missing ID via the type system?

[johnthagen]

Reviewed 19 of 19 files at r1.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @imnasnainaec)

[imnasnainaec]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @johnthagen)

---

src/rootReducer.tsx, line 22 at r1 (raw file):

Previously, johnthagen wrote…

Super minor, but the convention I've seen most is to place one space after // before a comment if we want to try to stay consistent across all of our code bases.

I matched the dominant format within the file. Could more global consistency be another pr?

---

src/backend/index.tsx, line 331 at r1 (raw file):

Previously, johnthagen wrote…

LocalStorage.getProjectId() returns "" if there is no project. Would it be more type safe if it returned undef so that we could check for if it exists? Not sure what would happen if you try to query for a blank project (probably a silent error to user)?

That would probably be be better. A later pr perhaps, since there's already so much in this one?

---

src/backend/index.tsx, line 332 at r1 (raw file):

Previously, johnthagen wrote…

Super minor, but I've usually seen it written TODO for what it's worth.

I've usually seen it that way too, but having Spanish-speaking collaborators in the past, I started using ToDo to minimize confusion ("todo" is Spanish for "everything").

---

src/components/ProjectSettings/ProjectExport/ExportProjectActions.tsx, line 18 at r1 (raw file):

Previously, johnthagen wrote…

These all take projectId?. What should happen if undef gets passed in here?

Is there anyway to ensure undef isn't passed in at a higher level and handled once to make the signatures on these functions tighter?

It's okay for that function to receive an undefined or "", because the function it calls checks the local storage for the current project if no project id is supplied (intentional decision).

---

src/components/ProjectSettings/ProjectExport/ExportProjectReducer.tsx, line 10 at r1 (raw file):

Previously, johnthagen wrote…

Another instance of a "" project ID. It's not clear to me what this means. Should it instead be projectId?: undef so we can handle missing ID via the type system?

That would perhaps be the best thing long term, to do along-side your first request (re. local storage).

[johnthagen]

---

src/rootReducer.tsx, line 22 at r1 (raw file):

Previously, imnasnainaec (D. Ror.) wrote…

I matched the dominant format within the file. Could more global consistency be another pr?

Sure thing.

[johnthagen]

---

src/backend/index.tsx, line 331 at r1 (raw file):

Previously, imnasnainaec (D. Ror.) wrote…

That would probably be be better. A later pr perhaps, since there's already so much in this one?

Sure thing.

[johnthagen]

I didn't find any issues with this PR, but would feel more comfortable if @jasonleenaylor reviewed and gave final approval due to the number of changes and me being relatively less familiar with the overall frontend design.

[jasonleenaylor]

Reviewed 15 of 19 files at r1, 3 of 3 files at r2.
Reviewable status: complete! all files reviewed, all discussions resolved

Removing the block to merging, some consistency changes can come later.