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

Chore: Import only lodash submodules #2041

Merged
merged 6 commits into from
Dec 12, 2023
Merged

Conversation

anshgoyalevil
Copy link
Member

@anshgoyalevil anshgoyalevil commented Dec 10, 2023

Which problem is this PR solving?

Description of the changes

  • Import only lodash submodules

How was this change tested?

  • locally

Super cool that it reduced the size taken by lodash bundle by 70.59% (master branch vs this)

Before:
image
lodash: 773.55 KB

After:
image
lodash: 227.43 KB

Checklist

Signed-off-by: Ansh Goyal <anshgoyal1704@gmail.com>
@anshgoyalevil anshgoyalevil requested a review from a team as a code owner December 10, 2023 15:02
@anshgoyalevil anshgoyalevil requested review from yurishkuro and removed request for a team December 10, 2023 15:02
Copy link

codecov bot commented Dec 10, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (4bdb8ac) 96.55% compared to head (8cc2692) 96.54%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2041      +/-   ##
==========================================
- Coverage   96.55%   96.54%   -0.01%     
==========================================
  Files         255      255              
  Lines        7625     7611      -14     
  Branches     1983     1983              
==========================================
- Hits         7362     7348      -14     
  Misses        263      263              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@yurishkuro yurishkuro added the changelog:bugfix-or-minor-feature 🐞 Bug fixes, Minor Improvements label Dec 10, 2023
_groupBy(allSpans, x => x.process.serviceName),
(value, key) => ({ key })
)
);
Copy link
Member

Choose a reason for hiding this comment

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

If I understand this, the goal is to get a unique list of service names, right? If so, why use groupBy at all, wouldn't this work (in scala syntax):

spans.map(_.process.serviceName).uniq()

?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. I have used a more concise function uniqBy here now.

Copy link
Member

@yurishkuro yurishkuro Dec 11, 2023

Choose a reason for hiding this comment

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

better, but could this not be written in fluent style like _uniqBy(...).map()?

Copy link
Member

@yurishkuro yurishkuro Dec 11, 2023

Choose a reason for hiding this comment

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

and perhaps you may remove the following loop

_uniqBy(allSpans, span => span.process.serviceName)
  .foreach(span => allDiffColumnValues.push(span.process.serviceName))

Copy link
Member

Choose a reason for hiding this comment

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

in fact, allDiffColumnValues is assigned once, so no need to push

allDiffColumnValues = _uniqBy(allSpans, span => span.process.serviceName)
  .map(span => span.process.serviceName);

I still think the most intuitive form is this:

allDiffColumnValues = _uniq(_map(span => span.process.serviceName));

Copy link
Member Author

Choose a reason for hiding this comment

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

wow, I literally ignored that for loop with a focus to replace the former lodash syntax with the new one.
This one seems neat

});
const tags = _map(availableTags, 'tags');
let tagKeys = _uniq(_map(_flatten(tags), 'key'));
tagKeys = _filter(tagKeys, o => o !== nameSelectorTitle);
Copy link
Member

Choose a reason for hiding this comment

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

This may be the equivalent, but could we do better? First, availableTags var is overloaded: starts a set of spans, then set of strings, bad design. And all these lodash ops are revisiting the same data that was already processed in the loop above - could we just calculate what we need right there?

Copy link
Member

Choose a reason for hiding this comment

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

At least we should rename the var to spansWithFilterTag

Copy link
Member Author

Choose a reason for hiding this comment

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

I tried playing with the former logic but it is getting a bit complex to accommodate the work we are taking out of lodash functions to the loops.

Signed-off-by: Ansh Goyal <anshgoyal1704@gmail.com>
Signed-off-by: Ansh Goyal <anshgoyal1704@gmail.com>
});
const tags = _map(availableTags, 'tags');
let spansWithFilterTag = _uniq(_map(_flatten(tags), 'key'));
spansWithFilterTag = _filter(spansWithFilterTag, o => o !== nameSelectorTitle);
Copy link
Member

Choose a reason for hiding this comment

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

this collection does not contain spans, now it's even more confusing. I was referring to L46 and above, where the objects in question are spans, but the collection is called availableTags

Copy link
Member Author

Choose a reason for hiding this comment

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

Got it. Thanks 🚀

Signed-off-by: Ansh Goyal <anshgoyal1704@gmail.com>
@@ -12,19 +12,22 @@
// See the License for the specific language governing permissions and
// limitations under the License.

import _ from 'lodash';
import _map from 'lodash/map';
Copy link
Member Author

Choose a reason for hiding this comment

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

We can get rid of this _map submodule too, using the built-in JS function. Should I go ahead with that change?

Copy link
Member

Choose a reason for hiding this comment

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

+1

const tags = spansWithFilterTag.map(o => o.tags);
let tagKeys = _uniq(_map(_flatten(tags), 'key'));
tagKeys = tagKeys.filter(o => o !== nameSelectorTitle);
spansWithFilterTag = [];
Copy link
Member

Choose a reason for hiding this comment

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

these are not spans anymore, this is just output. Could this not be simplified like this?

return [serviceName, operationName, ... tagKeys];

Copy link
Member

Choose a reason for hiding this comment

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

or _concat()

Copy link
Member Author

Choose a reason for hiding this comment

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

Used the Spread syntax, to remove _concat completely.

const allSpans = trace.spans;
if (nameSelectorTitle === serviceName) {
availableTags.push(operationName);
spansWithFilterTag.push(operationName);
Copy link
Member

Choose a reason for hiding this comment

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

these are not spans

}
}
availableTags = [...new Set(availableTags)];
spansWithFilterTag = [...new Set(spansWithFilterTag)];
Copy link
Member

Choose a reason for hiding this comment

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

could also do x = _uniq(x) here, more explicit than set-to-array transform.

Signed-off-by: Ansh Goyal <anshgoyal1704@gmail.com>
Copy link
Member

@yurishkuro yurishkuro left a comment

Choose a reason for hiding this comment

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

🎉

@yurishkuro yurishkuro merged commit 46f89af into jaegertracing:main Dec 12, 2023
10 checks passed
@anshgoyalevil anshgoyalevil deleted the ldsh branch May 13, 2024 07:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:bugfix-or-minor-feature 🐞 Bug fixes, Minor Improvements
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Import only lodash submodules
2 participants