Skip to content

pr05 Typescript #3: Migrate client/utils folder #3553

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 75 commits into
base: develop
Choose a base branch
from

Conversation

clairep94
Copy link
Collaborator

@clairep94 clairep94 commented Jul 26, 2025

pr05 Typescript Migration 3: Migrate the client/utils folder

IMPORTANT: Should be reviewed after #3540 for clarity

Context:

  • Rebuild of Pr05/migrate client utils clairep94/p5.js-web-editor#5 --> forgot to do git mv for the first few files and directly renamed, so this looks like deleting and creating a new file for git, and erases the previous history.

  • Migrate as much of the client/utils folder with the following steps:

  1. git mv someUtil.js someUtil.ts. If possible, commit without the no-verify flag, otherwise with no-verify.
    I forgot to add no-verify to my commit message in some of these initial ones
  2. Add unit test to secure current behaviour
  3. Check for all instances of useage for the utility function to determine types & edgecases of types
  4. Add types & handle edgecases & update test
  5. Refactor if beneficial
  6. Add JSDocs
  • I skipped the intellisense autogen files & the codemirror utility files due to unfamiliarity, but migrated most of the rest of the folder

Changes:

Please see annotations on files

  • apiClient
  • device
  • metaKey
  • language-utils
  • formatDate
  • consoleUtils
  • dispatcher
  • evaluateExpression
  • reduxFormUtils
  • getConfig (+ many instances of useage throughout the client folder)
  • NEW: parseStringToType

Notes:

I have verified that this pull request:

  • has no linting errors (npm run lint)
  • has no test errors (npm run test)
  • is from a uniquely-named feature branch and is up to date with the develop branch.
  • is descriptively named and links to an issue number, i.e. Fixes #123

const S3_BUCKET_URL_BASE = getConfig('S3_BUCKET_URL_BASE', {
throwErrorIfNotFound: true
});
const S3_BUCKET = getConfig('S3_BUCKET', { throwErrorIfNotFound: true });
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@khanniie what do you think of this update?

getConfig options param now has throwErrorIfNotFound, which throws and error if the value is not found (or is an empty string)
This allows the compiler to throw errors immediately when attempting a local build if these things are missing

I've done a search for all instances where getConfig is used and made a guess of what I think would be useful to fail at compile-time if the config variable doesn't exist, but this is totally a guess

Copy link
Collaborator

Choose a reason for hiding this comment

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

tysm!! appreciate you making the change! doesn't really affect the implementation but are we sure it's the compiler throwing the error and not the console at runtime? either way i think it's good we're throwing an error instead of letting it fail silently

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm I just tried this manually by removing API_URL from my local env and it didn't seem to throw in my local build, so I'm going to remove this!

Will look into doing the thing you mentioned where we have another module that checks for 'required' env variables at compile or build time

)}`;
previewScripts.src = `${
window.location.origin
}${getConfig('PREVIEW_SCRIPTS_URL', { nullishString: true })}`;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@khanniie I don't have this in my local env, which is auto gen from the env.example, so I assumed this was not fail-on-not-found worthy, what do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

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

hmmmm tbh I don't really know if it's necessary or not, maybe @raclim would know?

warn: !isTestEnvironment,
nullishString: false,
throwErrorIfNotFound: false,
throwErrorInTestEnv: false
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@khanniie
Without this, I wasn't able to test if getConfig throws errors when we set {throwErrorIfNotFound: true} because the env is 'test' when we run the test

What do you think, is there another way to set the env of the test run for a single test?

Another alternative would be to do {throwErrorIfNotFound: !isTestEnv} for whereever we're using getConfig, but I was thinking maybe that's not the cleanest to keep doing that when we use the function

Copy link
Collaborator

Choose a reason for hiding this comment

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

not sure if i understood the question exactly right, but i think there are ways to set the env for tests! i think you can override the values in the module?

https://stackoverflow.com/questions/48042200/invalidate-node-cache-when-using-jest

^ not sure if this above works for your case but we can definitely look into mocks / stubs for env if that's what you were wondering

@clairep94 clairep94 force-pushed the pr05/migrate_client_utils_folder branch from 999c62a to 8b3fee5 Compare August 15, 2025 19:00
@@ -3,8 +3,8 @@ import classNames from 'classnames';
import { useTranslation } from 'react-i18next';

type SkipLinkProps = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

this should be interface i think?

khanniie
khanniie previously approved these changes Aug 18, 2025
Copy link
Collaborator

@khanniie khanniie left a comment

Choose a reason for hiding this comment

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

it's looking really good!!! I had a few more tiny comments but overall thank you so much for your hard work!

const S3_BUCKET_URL_BASE = getConfig('S3_BUCKET_URL_BASE', {
throwErrorIfNotFound: true
});
const S3_BUCKET = getConfig('S3_BUCKET', { throwErrorIfNotFound: true });
Copy link
Collaborator

Choose a reason for hiding this comment

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

tysm!! appreciate you making the change! doesn't really affect the implementation but are we sure it's the compiler throwing the error and not the console at runtime? either way i think it's good we're throwing an error instead of letting it fail silently

)}`;
previewScripts.src = `${
window.location.origin
}${getConfig('PREVIEW_SCRIPTS_URL', { nullishString: true })}`;
Copy link
Collaborator

Choose a reason for hiding this comment

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

hmmmm tbh I don't really know if it's necessary or not, maybe @raclim would know?

* - type: 'START', 'STOP' etc
* - payload: additional data for that message type
*/
export type Message = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

interface?

@@ -0,0 +1,44 @@
type EvalResult = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

interface?

throwErrorIfNotFound?: boolean;
}

const defaultGetConfigOptions: GetConfigOptions = {
Copy link
Collaborator

Choose a reason for hiding this comment

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

warn: !isTestEnvironment,
nullishString: false,
throwErrorIfNotFound: false,
throwErrorInTestEnv: false
Copy link
Collaborator

Choose a reason for hiding this comment

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

not sure if i understood the question exactly right, but i think there are ways to set the env for tests! i think you can override the values in the module?

https://stackoverflow.com/questions/48042200/invalidate-node-cache-when-using-jest

^ not sure if this above works for your case but we can definitely look into mocks / stubs for env if that's what you were wondering

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr05 Grant Projects pr05 Grant Projects
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants