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

fix(cloud-templates): cast default number and boolean numbers to feel #121

Merged
merged 2 commits into from
Sep 13, 2024

Conversation

marstamm
Copy link
Collaborator

related to camunda/camunda-modeler#4517

Proposed Changes

We already cast Number and Boolean values to feel when they are changed, but keep the default value. This leads to problems when the default value is a true instead of "=true".

This PR casts the default value to feel if the property requires it.

Checklist

To ensure you provided everything we need to look at your PR:

  • Brief textual description of the changes present
  • Visual demo attached
  • Steps to try out present, i.e. using the @bpmn-io/sr tool
  • Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

@marstamm marstamm requested a review from a team September 12, 2024 09:28
@marstamm marstamm self-assigned this Sep 12, 2024
@marstamm marstamm requested review from barmac and abdul99ahad and removed request for a team September 12, 2024 09:28
@bpmn-io-tasks bpmn-io-tasks bot added the needs review Review pending label Sep 12, 2024
@@ -3,6 +3,7 @@ import { getBusinessObject } from 'bpmn-js/lib/util/ModelUtil';
import { is, isAny } from 'bpmn-js/lib/util/ModelUtil';

import { v4 as uuid } from 'uuid';
import { isSpecialFeelProperty, toFeelExpression } from './util/feelUtil';
Copy link
Member

Choose a reason for hiding this comment

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

Minor nit-pick: Let's rename the utility to CamelCase, i.e. FeelUtil.

I acknowledge that we already have some lowerCaseYesThatIsMe files in the code-base, but let's not introduce too many more of them, as the standard is starting with a capital letter.

Copy link
Collaborator Author

@marstamm marstamm Sep 13, 2024

Choose a reason for hiding this comment

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

Is that the convention we have? As I see it, the file name reflects the default export. Per convention, Classes and Components are written in PascalCase, hence a lot of our files are also PascalCase.

The utility files do not have a default export or exports a function. Since a function is usually camelCase (ignoring functional components), the file name will reflect this as well.

This is consistent with all existing utility files

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Cf. https://github.com/bpmn-io/bpmn-js-element-templates/blob/e8d563a5b4b5abcdaf88ffada30fd9c0c914c95e/src/cloud-element-templates/util/validate.js as an example.

Validator is a class, since it is in Validator.js. When making it a utility validate, the file name will reflect the contents and is named validate.js (lower case)

Copy link
Member

Choose a reason for hiding this comment

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

I can only look towards our different utilities in the eco-system, and they all seem to be historically upper-case - https://github.com/bpmn-io/diagram-js/tree/develop/lib/util.

Only recently we started lower-casing things in side-projects, but also not consistently. Predominently, utilities are still upper case, unless imported via index.js directly - https://github.com/bpmn-io/bpmn-js-element-templates/tree/main/src/utils.

👍 on reflecting the name / type of the default export, where it makes sense. But your utility does not provide a default export, but is a collection of various things - https://github.com/bpmn-io/bpmn-js-element-templates/pull/121/files#diff-ed2c638650f4cb053378f288c21bb35939630f122e9d0eb79f4924d62984a084.

Another debate is if "single function per file", with a default context is an appropriate way to slice things. Sometimes (but only sometimes) it makes sense.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree that we are not consistent in our naming schemes. In the context of this JSX project, I would argue that using camelCase for utilities helps with understanding the file structure better. Using Upercase primarily for Components helps with knowing what the contents of the file will be without having to open the file itself.

Predominently, utilities are still upper case

Only if they are closely related to a bpmn-js utility they are extending:

https://github.com/bpmn-io/bpmn-js-element-templates/tree/main/src/cloud-element-templates/util

But your utility does not provide a default export, but is a collection of various things

While the utility file does not have a default export, it still only exports functions and should therefore follow the naming convention for functions, rather than Components

Copy link
Member

Choose a reason for hiding this comment

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

No hard opinion, but if we want to keep naming consistent, I'd follow the unofficial core libraries rule of PascalCase everywhere (cf. bpmn-js and diagram-js).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Adjusted to PascalCase

Copy link
Member

Choose a reason for hiding this comment

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

In the end, stuff is usually auto-imported. For that reason, I'd discourage default exports.

Copy link
Member

@nikku nikku left a comment

Choose a reason for hiding this comment

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

Great stuff! 🎉

@nikku nikku merged commit 1222900 into main Sep 13, 2024
8 checks passed
@bpmn-io-tasks bpmn-io-tasks bot removed the needs review Review pending label Sep 13, 2024
@nikku nikku deleted the cast-default-values branch September 13, 2024 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants