feat(query-builder): add public api for commit and discard current state

[igdmdimitrov]

Closes #

Additional information (check all that apply):

• [ ] Bug fix
• [x] New functionality
• [ ] Documentation
• [ ] Demos
• [ ] CI/CD

Checklist:

• [ ] All relevant tags have been applied to this PR
• [ ] This PR includes unit tests covering all the new code (test guidelines)
• [ ] This PR includes API docs for newly added methods/properties (api docs guidelines)
• [ ] This PR includes feature/README.MD updates for the feature docs
• [ ] This PR includes general feature table updates in the root README.MD
• [ ] This PR includes CHANGELOG.MD updates for newly added functionality
• [ ] This PR contains breaking changes
• [ ] This PR includes ng update migrations for the breaking changes (migrations guidelines)
• [ ] This PR includes behavioral changes and the feature specification has been updated with them

[gedinakova]

@igdmdimitrov Currently, if I edit a condition in a subquery, it would commit the inner condition only. Nothing happens for the parent condition: On commit, the result is: Even if I commit at this point, the parent condition is not committed. Since the commit method is on the QB itself, I expect all conditions to be committed!

[teodosiah]

1. Change the entity in the nested query
2. Commit through API The empty expression is still in edit mode

[teodosiah]

If we clear the return fields and commit through API as follows: We would have @imincheva Should we change the appearance in this scenario in order to notify the user that this is not a valid expression?

[teodosiah]

• If we commit through API an expression with a column of type number without selecting operator the chip looks like the following:

• For other data types the chip in this scenario will be the following:

However, there is a valid Null operator that could be chosen and the chip would be the same:

@imincheva Do you have any suggestions how we should mark such invalid expressions once they are committed (through API), so they look similar regardless of their column data type and not the same as some valid expression?

[gedinakova]

An error is thrown on attempting to commit an inner query without conditions: The result on discard is:

Expected result: The result on commit to be what we have on discard, while on discard to delete the whole condition.

[gedinakova]

• If we commit through API an expression with a column of type number without selecting operator the chip looks like the following:

• For other data types the chip in this scenario will be the following:

However, there is a valid Null operator that could be chosen and the chip would be the same:

@imincheva Do you have any suggestions how we should mark such invalid expressions once they are committed (through API), so they look similar regardless of their column data type and not the same as some valid expression?

A decision was taken to throw an error on attempting to commit invalid state instead of going into too many weird scenarios after committing an invalid condition.

[gedinakova]

@igdmdimitrov

1. In the dev demo, modify any existing condition by deleting the search value
2. Exit edit mode on the editor

Result: The "commit" button stays enabled. canCommit() returns true. The searchVal is empty string (even for non-string fields):

Note: The issue is not observed when creating a new condition.

[gedinakova]

@igdmdimitrov

1. In the dev demo, clear the root group's return fields
2. Check the canCommit result > it returns false
3. Enter edit mode on the subquery without any other changes
4. Check the canCommit result

Result: It returns true. Expected result: It should return false because of the root group's state.