Skip to content
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

🪟 🎉 remove sub-1 hour frequency options #15708

Merged
merged 8 commits into from
Aug 18, 2022

Conversation

lmossman
Copy link
Contributor

@lmossman lmossman commented Aug 16, 2022

What

Resolves https://github.com/airbytehq/airbyte-cloud/issues/1272

This PR removes the sub-1 hour frequency options from the replication frequency dropdown, to encourage users to use frequencies that are in line with our stated limits and system expectations.

OSS users can still configure connections to run at any custom frequency through the API.

How

Removes the sub-1 hour frequency options from FrequencyConfig.json.

This PR also adds logic to include the connection's currently configured frequency in the dropdown, so as not to confuse users if they have a connection with a frequency that is not one of the default options in the dropdown.

Example screenshot of new default options:
Screen Shot 2022-08-16 at 4 59 40 PM

Example screenshot of a connection with some custom frequency already set:
Screen Shot 2022-08-17 at 10 51 27 AM

Recommended reading order

  1. FrequencyConfig.json
  2. formConfig.tsx
  3. ConnectionForm.tsx
  4. formConfig.test.ts

🚨 User Impact 🚨

Users will no longer see sub-1 hour frequencies in the replication frequency dropdown UI. OSS users can still configure any frequency through the API.

@lmossman lmossman requested a review from a team as a code owner August 16, 2022 23:57
@github-actions github-actions bot added area/platform issues related to the platform area/frontend Related to the Airbyte webapp labels Aug 16, 2022
if (!additionalFreqAlreadyPresent) {
frequencies.unshift(additionalFrequency);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This might be a good use-case for a set
But we'd need to sort on return.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think given that we know our frequency config is rather short (I mean we'll never talk about more than 100 entries here), converting this into a set (and handling the sorting ourselves) sounds like way more effort (even in terms of performance), than just iterating through the (rather small array) once.

frequency?.timeUnit === additionalFrequency.timeUnit && frequency?.units === additionalFrequency.units
);
if (!additionalFreqAlreadyPresent) {
frequencies.unshift(additionalFrequency);
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd actually suggest we add this to the end. I feel it's a bit weird, that this sits above the "Manual" option eventually. Also given that if they have a custom frequency, it might not be a "recommended" once, I feel putting it at the end might be preferred.

Copy link
Contributor 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 agree with the fact that it's not "recommended" so we shouldn't put it at the front. Would it make any sense to try to put it in sorted order with the other entries? My guess is that would be slightly more complicated than it is worth, and like you said since it is not recommended it might just make more sense to put it at the end anyway

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have updated this to push it onto the end instead. Here's what it looks like now in the UI:
Screen Shot 2022-08-17 at 10 51 27 AM

@lmossman lmossman force-pushed the lmossman/remove-sub-1-hour-frequencies branch from b7b52a9 to 0da519b Compare August 17, 2022 16:39
@lmossman lmossman requested a review from timroes August 17, 2022 17:49
@timroes
Copy link
Contributor

timroes commented Aug 17, 2022

@lmossman I just noticed we still have https://github.com/airbytehq/airbyte/blob/master/airbyte-webapp/src/config/utils.ts#L5 where we're reading from that file. This method seems to only be used to actually get a "human readable" version of the schedule to attach to segment events. Maybe to make this properly we work we can actually change this slightly, so that when we can't find the appropriate element inside the JSON file, we're simply concatenating the schedule.units and schedule.timeUnit together so it will return also something for those custom schedules. At that point we should make this method directly return the string and not an object from which we (currently) in all places anyway just read the .type property off.

@lmossman
Copy link
Contributor Author

lmossman commented Aug 17, 2022

I pushed a refactor of that util method to just use the values in the passed-in ConnectionSchedule, as we discussed over slack: 3e0bedd

@@ -0,0 +1,35 @@
import { ConnectionSchedule } from "core/request/AirbyteClient";

const frequencyConfig: Array<ConnectionSchedule | null> = [
Copy link
Contributor

Choose a reason for hiding this comment

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

We usually try to have named exports (the default exports) are left overs we're trying to eliminate. So since we're anyway touching this, could we please turn this into a:

export const frequencyConfig ...

instead of the default export at the bottom.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah yeah, this was mentioned in the style guide too - my bad! I've pushed this change

Copy link
Contributor

@timroes timroes left a comment

Choose a reason for hiding this comment

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

Tested locally with uneven numbers in a connection. Everything works and shows up as expected. One minor nitpick about exports left, once that's solved LGTM

@lmossman lmossman merged commit 81eac50 into master Aug 18, 2022
@lmossman lmossman deleted the lmossman/remove-sub-1-hour-frequencies branch August 18, 2022 16:49
rodireich pushed a commit that referenced this pull request Aug 25, 2022
* remove sub-1-hour frequency options, and add current connection frequency to dropdown

* fix e2e test

* add additional frequency to end of options instead of beginning

* use better jest expect methods

* refactor getFrequencyConfig util function to just use connection schedule values

* move frequencyConfig to a TS file and remove unnecessary type field

* use named export

Co-authored-by: Tim Roes <tim@airbyte.io>
@st0302
Copy link

st0302 commented Aug 28, 2022

who can tell me, how to add a new option , eg:15 minutes

@st0302
Copy link

st0302 commented Aug 29, 2022

What

Resolves https://github.com/airbytehq/airbyte-cloud/issues/1272

This PR removes the sub-1 hour frequency options from the replication frequency dropdown, to encourage users to use frequencies that are in line with our stated limits and system expectations.

OSS users can still configure connections to run at any custom frequency through the API.

How

Removes the sub-1 hour frequency options from FrequencyConfig.json.

This PR also adds logic to include the connection's currently configured frequency in the dropdown, so as not to confuse users if they have a connection with a frequency that is not one of the default options in the dropdown.

Example screenshot of new default options: Screen Shot 2022-08-16 at 4 59 40 PM

Example screenshot of a connection with some custom frequency already set: Screen Shot 2022-08-17 at 10 51 27 AM

Recommended reading order

  1. FrequencyConfig.json
  2. formConfig.tsx
  3. ConnectionForm.tsx
  4. formConfig.test.ts

🚨 User Impact 🚨

Users will no longer see sub-1 hour frequencies in the replication frequency dropdown UI. OSS users can still configure any frequency through the API.

How to add the option "Every 17 minutes" in version 0.40.1 , thx

@lmossman
Copy link
Contributor Author

lmossman commented Aug 30, 2022

@st0302 in order to use a custom frequency for a connection, you will need to use the Airbyte API to create or update a connection, setting the schedule and scheduleData.basicSchedule fields to the value you want to use. We are currently working on deprecating the schedule field in the API, after which you will just need to set scheduleData to the desired value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/frontend Related to the Airbyte webapp area/platform issues related to the platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants