Any missing methods?

[jimmed]

Are there any highly-desirable lodash/underscore methods that slapdash is missing?

[oliverwoodings]

From the readme:

there is no objectFind because it is not that useful

I'd disagree - i've already had situations where i've wanted this from slapdash. Right now I have to do:

_.find(_.keys(obj), function (key) {
  var value = obj[key];
  ...
})

[jimmed]

Good call! I'll raise a PR shortly

EDIT Small amount of bikeshedding between me and @oliverwoodings resulted in me adding _.values instead.

[roberttod]

I use pick all over the place in Jolt and for a number of other projects, can we include it here?

[jimmed]

pick

Definitely: although I would be inclined to only support pick(obj, string[]) instead of the varargs supported by lodash. That way I can avoid juggling arguments - how does that sound?

[roberttod]

I actually opt out of ever doing it the varargs way so I am happy with that.

[alanclarke]

Note that the point of slapdash is not to reinvent a comprehensive set of helper functions, but to have a shared implementation of a small selection of the most commonly used ones, so that we can remove kbs from smartserve.js

[alanclarke]

for example, if this approaches 4kb, why bother replacing underscore?

[jimmed]

Agreed - and while I'm trying to avoid feature creep, these are very useful to have, and are common patterns in deliver-lib, where we're trying to cut the most cruft.

[alanclarke]

👍

[roberttod]

Thing is, for example, if I go around pasting the snippet for any at the bottom of any file that needs it, then doesn't that end up increasing the size of smartserve even more anyway?

[alanclarke]

well yeah, and in that case we would include the method or document a simple way to achieve the same

[alanclarke]

but if it turned out you never needed .any, because, for example, for 99% of cases .any is basically .find but coerced into a boolean, then we would be better off using .find, no?

[roberttod]

True but I feel like I still find myself calling it any because that is easier to read and figure out what it does than _.find(_.map(array, callback, context), _.identity).

[alanclarke]

actually find accepts a function, so you don't need the map

[alanclarke]

so in that case its more like !!_.find(arr, callback)

[alanclarke]

like, if its really impractical not to, we can and should add stuff, but lets try to avoid if possible

[roberttod]

Yeh, I think Boolean(_.find(arr, callback)) would be fine.

[roberttod]

Can we get a _.memoize function?

[jimmed]

Can we get a _.memoize function?

Probably not -- I talked to @Olical about this over a coffee, and we agreed it might make sense to have another small library (of the same ilk as slapdash) which deals with timeouts/throttling/debouncing/memoization and all that good stuff.

[jimmed]

Closing this issue - to bikeshed a specific method we can start a new thread.

[oliverwoodings]

Could call it otherdash

On 31 May 2016 at 10:01, jimmed notifications@github.com wrote:

Closed #4 https://github.com/qubitdigital/slapdash/issues/4.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qubitdigital/slapdash/issues/4#event-676714731, or mute the thread https://github.com/notifications/unsubscribe/AAl7C1kDERLW4pG89BR9X2uMVBILlRLdks5qG_j-gaJpZM4IA6yd .

[roberttod]

@jimmed what reasons did you have for putting those in a different library?

[jimmed]

Slapdash isn't a replacement for lodash/underscore - it's a solution to unpredictable execution environments preventing us from using native browser methods.

At most, it's a wrapper around the ES5 array/object methods (and some of the ES6 ones). If memoization depended on any of those methods, then I could justify including it (along with other methods) - but it doesn't as far as I know.

I'm starting to think it would make more sense if I removed any reference to lodash/underscore from the docs, renamed it to 'slopdish' and referred to it as σ instead of _, because the implication that it's based on lodash is twisting the point of the library.

what reasons did you have for putting those in a different library

To actually answer the question: because they don't belong in this library.

[alanclarke]

@jimmed don't forget that we literally started this project in order to replace underscore

[alanclarke]

because we were hoping to remove 3kb from smartserve.js

[roberttod]

I feel like it would be more practical to just put everything here since you have done all the groundwork with building etc. Also, since the other library would be included in smartserve anyway we wouldn't be gaining anything in a split except I guess a separation of concerns.

[jimmed]

Just to reflect on the hangout me and @roberttod had (and to massively backpedal on my own idealism):

• Slapdash is there to make smartserve bundles smaller + safer. If there's a reusable method we're going to be using in 99% of smartserve bundles, then it should probably be included.
• If a method is only used in a couple of deliver-lib modules, it probably doesn't belong in slapdash.

[Olical]

Kind of placeholder name, but here's my "extra" methods I think should be moved to slapdash. https://github.com/qubitdigital/visitor-engine-utils/blob/master/src/extra.js

I have a fairly large test suite for them in that repo too. May come in handy.

On 2 June 2016 at 17:35, jimmed notifications@github.com wrote:

Just to reflect on the hangout me and @roberttod https://github.com/roberttod had (and to massively backpedal on my own idealism):

• Slapdash is there to make smartserve bundles smaller + safer. If there's a reusable method we're going to be using in 99% of smartserve bundles, then it should probably be included.
• If a method is only used in a couple of deliver-lib modules, it probably doesn't belong in slapdash.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qubitdigital/slapdash/issues/4#issuecomment-223347872, or mute the thread https://github.com/notifications/unsubscribe/AATPXdkkkEQV8dDD1_qRHMDSFxvmy-00ks5qHwY0gaJpZM4IA6yd .

Oliver Caldwell

Frontend Engineer

Twitter: @OliverCaldwell https://twitter.com/OliverCaldwell Mobile: 07503 154 687

Office: 02033 280 739

Qubit

20 Broadwick Street

London

W1F 8HT

Download the recent Forrester report where Qubit is championed as a feature rich marketing-centric solution, with best-of-breed offerings for analytics, A/B testing and optimization, as well as strengths in product recommendation: Market Overview: Digital Customer Experience Delivery Platforms http://www.qubitproducts.com/research/forrester-market-overview-digital-customer-experience-delivery-platforms?pagination=resources&type_1=4

This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. Thanks.

[alanclarke]

and boom - proof that our recruitment process is relevant

[jimmed]

That's stellar @Olical! If you raise a PR with your extra methods + test suites merged in, I'll gladly review and pull.