Inline variable doesn't work with destructured variable declarations about abracadabra HOT 5 CLOSED

Hello @noway 👋

I've got good news: the pattern you reported is now supported 🎉
I completed the implementation to handle destructured object patterns. It should work with complex objects too (nested cases, rest element, etc.).

I'm not closing the issue yet as it still doesn't handle destructured array patterns (e.g. const [userId] = session). But that should be faster to implement now that we take care of object patterns.

It will be shipped in the next release (v0.8.0), on Sunday 👍

from abracadabra.

Hi @noway 👋

Thank you for reporting this. Indeed, "Inline Variable" only works with Identifier for the moment. I didn't thought about destructured variables. Good one!

I'll work on it to get it fixed asap.

Note to myself, also need consider scenarios like:

const { userId, playerId } = session;
messages.map(message => ({ userId }));

If the selection is on userId, then the result should be:

const { playerId } = session;
messages.map(message => ({ userId: session.userId }));

from abracadabra.

Hi there 👋

Let me give you some news on that:

• I started working on it. As I expected, there are some edge cases to consider if I don't want to introduce bugs (e.g. handle complex stuff like const { user: { id } } = session.data;)
• So I started by refactoring the implementation of "Inline Variable" to extend the behaviour to such cases.
• I might deliver the case of ObjectPatterns first, and then think about ArrayPatterns (e.g. const [userId] = data;). Unless I have to tackle all of them because of nested scenarios (e.g. const { userData: [userId] } = data;).

So, it's on track, but it takes some time.

Also, I will probably hold it for a moment because there are some refactorings / improvements I personally need to develop first.

Finally, I reconsidered whether that was a bug or not. I came up with a more precise definition:

• I consider "a bug" a refactoring that changes the behavior of existing code.
• I consider "an improvement" a change that would optimize the result of a refactoring, or that would handle scenario that are not currently handled. Which is the case here I think.

So don't be surprised: I changed the "bug" label for "improvement" in that sense. Technically, nothing is broken. But this scenario is not handled yet, and we'd like to handle it for sure 😃

When I'll be done with the essential refactorings that I need, my prioritization process will be: Bug > Improvement > New refactoring. Which means this one will be my next top-priority 😉

I hope that will give you a clearer vision on how I'm working backstage. I think this one will be done before October.

from abracadabra.

@noway as I said, implementing the array pattern was easier now that the object pattern was implemented.

It's now fully supported. The full support with array patterns will be shipped in the next release (probably on Sunday, I tend to release a new version every Sunday 😄).

I hope that will be as helpful to you as it is to me. Thanks again for pushing it 👍

from abracadabra.

Okay makes sense. BTW, just to mention, I would be fine with having to perform 2 operations: "Refactor destructured declaration to normal declaration" first and then "Inline variable". Although solving the issue on the core level is definitely better, you can build a workaround which just changes destructured declaration to a normal declaration as a step.

Don't want to distract you from your current course of action of course. Maybe such a refactoring can be a separate refactoring.

from abracadabra.