-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Conversation
if (!additionalFreqAlreadyPresent) { | ||
frequencies.unshift(additionalFrequency); | ||
} | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b7b52a9
to
0da519b
Compare
@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 |
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> = [ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this 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
* 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>
who can tell me, how to add a new option , eg:15 minutes |
How to add the option "Every 17 minutes" in version 0.40.1 , thx |
@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 |
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:

Example screenshot of a connection with some custom frequency already set:

Recommended reading order
FrequencyConfig.json
formConfig.tsx
ConnectionForm.tsx
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.