-
Notifications
You must be signed in to change notification settings - Fork 409
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
#2215: add group in TOC toolbar #3797
Conversation
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.
Here the things I noticed:
-
When I delete a layer, all new groups are removed
-
If I use a
.
(dot) as the name of the group (for instance geo-solutions.it), then I open the layer properties, the groups selector i seegeo-solutions/it
-
If a group is selected we are going to add the layer/group from the button as a sub-group. Maybe in this case the tooltip should show something like "add sub-group to the selected group" or "add layer to the selected group". Using the name of the group in the tooltip is a plus.
-
Wrong tooltip for group visibility button (I verified this issue already exists on dev)
Here some things that may be confusing:
- When I open the catalog from the TOC the layer is added to the selected group, when I do it from the menu, the layer is added to the "Default" group. This may confuse the user.
- When I select a group to add layers to it, all it's layers in the group are selected, too. When I add a new layer to the selected group, this new layer is not selected. This looks somehow correct to me, but may be confusing. Just wanted to make you notice it.
This gif describes both layer selction and add from catalog issues:
* @param {object} properties the properties to set, as key (property name), value pairs | ||
* @return {object} of type `SET_CONTROL_PROPERTIES` with control and properties | ||
*/ | ||
function setControlProperties(control, ...properties) { |
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.
Why not directly the object? I think is more explicit that the array:
setControlProperties('mycontrol', 'a', 1, 'b', 2); // less intuitive
setControlProperties('mycontrol', {a:1, b: 2}) // more intuitive
Notice. The documentation tells something different. I didn't try yet, but documenting spread operator may work using this syntax @param {...object} myParam
(JSDoc 3.4.3). Please try (or refactor as suggested)
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.
Because using ...properties is more functional friendly (partial application) and in fact my first usage of it took advantage of partial application. Eventually we can also support both syntaxes
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.
Now I see. That's cool 👍
I should not provide both to avoid confusion.
So you could one of the following:
- Change the documentation to specify better how to use the action, maybe with an example
- Make the properties an object and change all the
.bind
with something like
( properties ) => setControlProperties('myControl', { {a: 1, b: 2}, ...properties} }
Do what you think is better.
@offtherailz "When I open the catalog from the TOC the layer is added to the selected group, when I do it from the menu, the layer is added to the "Default" group. This may confuse the user." |
…ayer removed, fixed problem with dot in group name
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.
Good. Almost done
Please look at my comments (1 inline, 1 on PR) and try to solve translation file conflict
Description
Improvements to the TOC:
Issues
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x", remove the others)
What is the current behavior? (You can also link to an open issue here)
Adding a new group or adding a layer to an existing group is complicated.
What is the new behavior?
Adding a new group or adding a layer to an existing group is easier.
Does this PR introduce a breaking change? (check one with "x", remove the other)
If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information: