Reason: [refmt] Don't remove function braces for single line functions.

[eldh]

Currently, refmt changes things like () => {doSomething();} to () => doSomething();. This becomes annoying when using refmt to format on save if you're trying to debug or change single line functions. I think it would be nicer if refmt didn't remove function parens.

[yawaramin]

If you're trying to debug or change a single-expression function, maybe a workaround is to add a second expression between the braces before you save?

[eldh]

Yes, obviously there are workarounds, this is just a matter of convenience. I think the () => doSomething(); form is nicer to look at, but less convenient if you want to change the code.

I might be one of few people who would prefer a different behaviour. Still I thought it was worth opening an issue.

[sgrove]

@yawaramin I immediately write let myNewFn = () => {();()}; when starting a new fn, but this is 1. a learned response to stop the pain 2. a lot of boilerplate I'd rather not have.

I definitely would just prefer consistency of always having the braces, personally. Not sure what the advantage of removing them in this case (the fn declaration case) is.

That said, it's not the end of the world, I could probably just write an emacs macro to do the boilerplate.

[jordwalke]

I think that both Reason and ES6 benefit from braceless function bodies with things like List.map(x => x + 1, myList).

We can solve this by retaining information about whether or not braces were typed when parsing. We can store it in a ppx attribute on the expression. {} will imply that they always break though (just a warning).

[eldh]

We can solve this by retaining information about whether or not braces were typed when parsing. We can store it in a ppx attribute on the expression. {} will imply that they always break though (just a warning).

Sounds good to me. :)

[yawaramin]

A perhaps simpler approach is to make it easy to disable and enable refmt in a smart but predictable way while editing. Thinking what would happen if we accomplished this–we'd be able to make our edits without interference while changing/debugging the code, and then signal that refmt is OK once we're done.

This smart on/off signal would then be the main thing we'd need to figure out. We could make it an editor command, but that would be one more command to remember. We could make it a 'pragma comment' like /* norefmt */ that would signal refmt to ignore this file. The advantage would be it would be easy to send the 'turn refmt on again' signal–just delete the pragma.

[sgrove]

Ah, but I want it to be constantly formatting, but this inconsistency is
the only thing that's painful. I can easily (temporarily) disable refmt in
my editor if I need to.

On Sun, Feb 11, 2018 at 3:01 PM, Yawar Amin [e-mail]
wrote:

A perhaps simpler approach is to make it easy to disable and enable refmt
in a smart but predictable way while editing. Thinking what would happen if
we accomplished this–we'd be able to make our edits without interference
while changing/debugging the code, and then signal that refmt is OK once
we're done.

This smart on/off signal would then be the main thing we'd need to figure
out. We could make it an editor command, but that would be one more command
to remember. We could make it a 'pragma comment' like /* norefmt */ that
would signal refmt to ignore this file. The advantage would be it would be
easy to send the 'turn refmt on again' signal–just delete the pragma.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/reason/issues/1813#issuecomment-364798311,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACJ4Hfk740__luAUrkW3vOSh7Xmay27ks5tT3FDgaJpZM4SBFW7
.

[jordwalke]

I think while editing via save, you want some formatting a relaxed. With an explicit format command you want it to be more strict.

[eldh]

I think having formatting on save provides a useful signal that my code is syntactically correct (in addition to fixing my sloppy indentation etc).

Perhaps having a limited config, similar to Prettier, could be an alternative to having different formatting modes?

[jordwalke]

What is a "limited config"?

[eldh]

I meant "limited" as in just a few available options, similar to what prettier has.

[jordwalke]

I just feel that people request a "limited" config, but what they actually want are things like "feedback that my file is valid syntax upon save". What people ask for doesn't always convey exactly what it is they actually want.

[kennetpostigo]

In most cases when your code doesn't format it is because theres something wrong in your code. both the editor will mark the portions where the error is found and bs/bs-native will give you a nice error message for it. This is just from my personal experience using refmt, other tooling will almost always make it obvious for you why refmt is not being ran.

[eldh]

What people ask for doesn't always convey exactly what it is they actually want.

Yep, this is true. I'm just wondering if having different modes could be more confusing to users than having a config. But I'm not sure which approach is the best solution for the problem at hand, or which approach comes with the worst drawbacks.

My thinking is that prettier has done all this bike-shedding and "solved" the problem (also if familiarity for JS devs is a goal within itself using the same approach has that benefit). Maybe this is not right for refmt, I can definitely see the appeal in not having a config!

[anmonteiro]

refmt preserves braces now. closing.