Add support for outdenting string arguments.

[treshugart]

I'm not sure what your stance is on this but I thought I'd raise a PR just in case, as opposed to just raising an issue.

Use case

My use case for this is that we're using outdent to outdent code blocks for our Code component that highlights the input text:

<Code
  text={`
    Needs
      outdenting
  `}
/>

We could use it as part of that template literal, but what we want is for outdenting to automatically happen on the template strings in the component. In order to do this, we need to be able to format strings. Our current solution is to trick outdent by providing it an array with the raw property like so:

// @flow

type LitArray = Array<any> & {
  raw: Array<string>,
};

// This converts a string to the shape of a parsed literal that the outdent
// lit function uses.
export function strToLit(str: string): LitArray {
  const strAsLitArr: any = [str];
  Object.defineProperty(strAsLitArr, 'raw', {
    configurable: true,
    value: [str],
  });
  return strAsLitArr;
}

However, it feels like providing this behaviour as part of outdent itself is a far better idea.

Testing

I've tested locally using npm test and everything passes. However, we're getting the following error in CI:

ERROR: test/spec/spec.ts[1, 24]: Module 'chai' is not listed as dependency in package.json

Are you aware of this? If not, I can investigate and fix.

[cspotcode]

Thanks for the PR!

I want outdent to intentionally avoid touching the contents of interpolated values. So it'll remove indentation from the template literal, as it statically appears in source code, but never touch the contents of a value (even if that value is a string with newlines and whitespace). Buy that doesn't affect your use case; you're not even invoking outdent as a template tag; you just want to give it a string.

I'm also paranoid about overloading a single function with too many signatures. We already have two: one accepting a template literal array, the other accepting an options object. I can't think of a way this would break in the future, but you never know...

How about having outdent.string(stringValue)? It'll do exactly what you want: strip indentation from a string.

Sorry if this response is ignoring details you've already addressed in your PR; I'm not at my computer but I'll read the code later.

[treshugart]

I'm also paranoid about overloading a single function with too many signatures.

I felt the same way but wanted to err on the side of convention here.

How about having outdent.string(stringValue)? It'll do exactly what you want: strip indentation from a string.

My original idea was along these lines. I'll happily update. The only thing would be choosing a good name. I'm ambivalent about outdent.string for a couple reasons:

1. It feels like a separate export.
2. string is reserved in typed langs like TS (if making it an export).

How would you feel about a named export, but called something like outdentString? If you're pretty set on outdent.string, then I'm totes fine with that, but thought it was worth bikeshedding since it'll be the public API :)

[cspotcode]

Sounds good, I like outdentString. And yeah, I agree, we should also do it as a named export. Doing it as a method too allows piggybacking on any options the user has configured. Like stripLeadingNewline. But I guess we could also support the option-bag signature for outdentString the same as with outdent. So a user would ` import {outdentString}` and then `outdentString({/*options here */})('string to be outdented');`

…

On Mar 11, 2018 9:31 PM, "Trey Shugart" ***@***.***> wrote: I'm also paranoid about overloading a single function with too many signatures. I felt the same way but wanted to err on the side of convention here. How about having outdent.string(stringValue)? It'll do exactly what you want: strip indentation from a string. My original idea was along these lines. I'll happily update. The only thing would be choosing a good name. I'm ambivalent about string for a couple reasons: 1. It feels like a separate export. 2. string is reserved in typed langs like TS. How would you feel about a named export, but called something like outdentString? If you're pretty set on outdent.string, then I'm totes fine with that, but thought it was worth bikeshedding since it'll be the public API :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW-uPJWVYNU0Yh5G1loWiUXturzSt9wks5tdc_ggaJpZM4Sl8n2> .

[treshugart]

Re options, that's a fairly compelling reason, so your idea of outdent.string is far more palatable. This is especially since the API is unlikely to be growing any more than adding string. I'll update it to outdent.string to see how it looks. It's easy to convert to a named export if we feel that's better overall.

Thanks for the feedback!

[cspotcode]

Sounds good, looking forward to it. Thank you for pointing out the CI failures; I pushed a fix to master.

[treshugart]

This will currently be breaking the build. I have absolutely no idea how to type this in TS. Halp.

[treshugart]

I'm use Flow a bit, so my TS knowledge is limited. Basically, what I want to express is something like this: https://flow.org/try/#0PQKgBAAgZgNg9gdzCYAoVUCuA7AxgFwEs5sxcAnAUwEN9KAKa8gcwC4wAjOOGG7ASnYBnfOULZmYAD5gAKpRFgA3qjBhCUMIxb9lqsAEgq+TOVIBycwG59AX324SiuooC8W3a4B8YSzbUu+AB0ALaU+AAWcAAmYO70nj5++sampIE29qj4AJ4ADpRgAGKk8YlgImIS2fmF8m7FpABkemphkTHsJai2NkA.

[cspotcode]

No worries, I'll make a commit to fix the types.

type Fn = () => string;
type Test = Fn & {
  method: Fn
};

That actually works in TypeScript; it was just balking at augmenting a function without first declaring the extended interface. (outdent as Outdent).string = does the trick.

One of these days I'll learn some Flow.

[treshugart]

Ok, that would explain my confusion then. So close!

[cspotcode]

@treshugart I pushed some commits, and now all tests are passing. What do you think? If everything looks good to you I'll publish a new version.

[treshugart]

Yeah, LGTM and thanks again :)

[cspotcode]

@treshugart I just published 0.5.0 to npm. Let me know if you encounter any issues.

[treshugart]

Thanks @cspotcode, will do!