2023-10-04 09:42:02 +02:00
|
|
|
import { validateFeatureNamingExample } from './ProjectEnterpriseSettingsForm';
|
1-1320: allow you to update example with no pattern + update state better (#4623)
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
2023-09-07 08:18:18 +02:00
|
|
|
|
|
|
|
describe('validateFeatureNaming', () => {
|
|
|
|
test.each(['+', 'valid regex$'])(
|
|
|
|
`if the featureNamingPatternError prop is present, it's always valid: %s`,
|
2023-10-02 14:25:46 +02:00
|
|
|
(pattern) => {
|
1-1320: allow you to update example with no pattern + update state better (#4623)
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
2023-09-07 08:18:18 +02:00
|
|
|
const result = validateFeatureNamingExample({
|
|
|
|
pattern,
|
|
|
|
example: 'aohutnasoehutns',
|
|
|
|
featureNamingPatternError: 'error',
|
|
|
|
});
|
|
|
|
|
|
|
|
expect(result.state).toBe('valid');
|
2023-10-02 14:25:46 +02:00
|
|
|
},
|
1-1320: allow you to update example with no pattern + update state better (#4623)
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
2023-09-07 08:18:18 +02:00
|
|
|
);
|
|
|
|
test(`if the pattern is empty, the example is always valid`, () => {
|
|
|
|
const result = validateFeatureNamingExample({
|
|
|
|
pattern: '',
|
|
|
|
example: 'aohutnasoehutns',
|
|
|
|
featureNamingPatternError: undefined,
|
|
|
|
});
|
|
|
|
|
|
|
|
expect(result.state).toBe('valid');
|
|
|
|
});
|
|
|
|
test(`if the example is empty, the it's always valid`, () => {
|
|
|
|
const result = validateFeatureNamingExample({
|
|
|
|
pattern: '^dx-[a-z]{1,5}$',
|
|
|
|
example: '',
|
|
|
|
featureNamingPatternError: undefined,
|
|
|
|
});
|
|
|
|
|
|
|
|
expect(result.state).toBe('valid');
|
|
|
|
});
|
|
|
|
|
|
|
|
test.each([
|
|
|
|
['valid', 'dx-logs'],
|
|
|
|
['invalid', 'axe-battles'],
|
|
|
|
])(
|
|
|
|
`if example is %s, the state should be be the same`,
|
|
|
|
(state, example) => {
|
|
|
|
const result = validateFeatureNamingExample({
|
|
|
|
pattern: '^dx-[a-z]{1,5}$',
|
|
|
|
example,
|
|
|
|
featureNamingPatternError: undefined,
|
|
|
|
});
|
|
|
|
|
|
|
|
expect(result.state).toBe(state);
|
2023-10-02 14:25:46 +02:00
|
|
|
},
|
1-1320: allow you to update example with no pattern + update state better (#4623)
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
2023-09-07 08:18:18 +02:00
|
|
|
);
|
2023-09-13 08:22:55 +02:00
|
|
|
|
|
|
|
test('the pattern gets an implicit leading ^ and trailing $ added', () => {
|
|
|
|
const result = validateFeatureNamingExample({
|
|
|
|
pattern: '[a-z]+',
|
|
|
|
example: 'not.valid',
|
|
|
|
featureNamingPatternError: undefined,
|
|
|
|
});
|
|
|
|
|
|
|
|
expect(result.state).toBe('invalid');
|
|
|
|
});
|
1-1320: allow you to update example with no pattern + update state better (#4623)
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
2023-09-07 08:18:18 +02:00
|
|
|
});
|