Repository navigation
Request for alternative import syntax to improve auto-complete experience #2371
Description
Consider the following import statement:
import { int, float } from '../lang';
With auto-suggest I need to start this by typing:
import {} from '../lang';
Then I can go back inside the {} and get auto-suggestions.
It would be very nice if TypeScript supported an alternate syntax for the same expression that was more conducive to auto-complete features.
For example:
import from '../lang' { int, float };
This doesn't introduce any confusion or ambiguity about the meaning of the expression, either to the transpiler or the human reader, yet it provides a time-saving experience to the author when taking advantage of auto-complete features. I can now simply type the expression naturally from left to right, and get auto-suggestions/completions for both the from '...' and {}.
There are other cases where an alternate syntax would be beneficial. I will update this issue as I compile a list. Hopefully others will comment with suggestions as well.
Activity
danquirk commentedon Mar 16, 2015
You're right that this is an awkward piece of syntax for tooling, but new alternate syntax is not the solution you want here. There is a simple and easy solution that doesn't require altering the language and diverging from ES6 syntax though: code snippets. It would look sort of like this:
When you type 'imp' you should get a completion that is a snippet for the right import syntax. After committing the snippet (via enter, tab, space, etc) the cursor should be placed on the RHS to type the actual module name. After committing that text (via enter or tab) the cursor jumps back to the import names where you now can get completion suggestions since the module name has been written.
gregdorval commentedon Mar 17, 2015
This is a good example of the difference between the developer mindset and
the designer mindset.
The developer comes up with a technology solution that assists the user in
adapting to the product.
The designer aims to adapt the technology to the natural processes of the
user.
In this case the target users are themselves developers, so you might think
it's not a big deal. However, it actually results in one decision, from a
developer mindset, sending the message to thousands of other developers
that this mindset is the best way to address the user experience.
I'm sure we could debate this until we are old and grey, but consider the
difference between the user satisfaction numbers of iPhones vs Android
phones. Which of the user experiences is driven almost entirely from the
designer mindset? (Yeah, I know, TypeScript is a Microsoft project...
That's why I left them out of the analogy)
I'll add the disclaimer that I've spent my entire career as a designer who
every once in a while learns a new development technology in order to get a
PoC in front of clients or investors. I do recognize the progress being
made in making it quick and relatively painless to develop robust and
impressive solutions, however I remain constantly reminded that the
industry is still driven by the notion that code in hand is more valuable
than taking the time to understand who the code is being written for.
Take my opinions with as many grains of salt necessary. It's my intention
for this to be constructive as opposed to insulting.
On Monday, March 16, 2015, Dan Quirk notifications@github.com wrote:
Greg Dorval
greg.dorval@gmail.com
Phone: (613) 686-1508
Skype: greg.dorval
BBM PIN: 54BB8FAF
https://plus.google.com/+GregDorval https://twitter.com/gregdorval
https://twitter.com/gregdorval
http://navcanada.ca
https://twitter.com/gregdorval https://plus.google.com/+GregDorval/posts
http://ca.linkedin.com/in/gregdorval
https://mail.google.com/mail/u/0/greg.dorval
danquirk commentedon Mar 17, 2015
We, and especially I, most definitely take the user experience seriously. You'll find more than a few comments from me throughout our issue tracker on where we're failing on that front (whether in the language itself or in the tooling) and what must be fixed. In this case you're simply not understanding the true costs and trade offs of the two proposed solutions. We cannot change the ES6 module syntax, that ship has sailed, it is not under our control, we can only provide another piece of input to the larger committee (which we have/did/do). We have to accept that the majority of future JavaScript brought to TypeScript will use this syntax that you do not like (for the record, I do not like it either, it clearly was designed without prioritizing the tooling related featured). So even if we take your proposed solution, the majority of people will not be able to benefit from it because they have tons of existing code that uses the JavaScript style and will want to remain consistent. On the other hand, by introducing our own syntax we risk future incompatibilities with JavaScript if they ever do change/augment their syntax, we require JavaScript developers to learn a new syntax, and we diverge further from JavaScript. This actually makes the user experience worse by having two pieces of different syntax that do identical things (particularly the initial on boarding experience for new TypeScript users), which is precisely why most languages try to avoid doing that sort of thing.
We very rarely alter expression level syntax like you're proposing, and that's for good reasons, not because we don't prioritize the quality of the user experience. TypeScript is intended to be a typed superset of JavaScript. If we repeatedly alter expression level syntax for relatively minor gains then we will fail to maintain that design and end up with a very different language that simply compiles to JavaScript. The proposal I've shown above is exactly the type of UX developers are used to in a variety of different IDEs in order to speed up writing out boilerplate code. Snippets like this have been a frequently requested feature in TypeScript specifically since we didn't support them as well as other Visual Studio languages and other editors.
We are not an iPhone app. We cannot simply make changes and break that functionality later if we decide we don't like it. Likewise any change we make today risks making any future designs harder for ourselves if we use up the valuable, limited design space that syntax and semantics affords us. The language decisions we make we live with forever and impact our future decisions forever.
Yes, in an ideal world the ES6 syntax would be closer to what you're proposing and autocomplete would 'just work' without any extra tooling support. In reality we have to work with what's there and the snippet experience I showed above is a pretty solid solution that you'll find is actually quite natural and does not require any significant change in workflow or mental model.
RyanCavanaugh commentedon Mar 17, 2015
See also #2370 for discussions of how no one really likes the ES6 module import/export syntax. It's frustrating for us, too.
The whole problem of how syntax influences tooling is one the team is intimately aware of -- one reason C# LINQ syntax moved the
fromclause to the front of the expression (rather than in the middle like SQL or Python does) was so that the tooling experience could be great. It's just a trade-off TypeScript has to make in order to be more JavaScript and less its own language by itself.gregdorval commentedon Mar 17, 2015
I completely understand that we don't operate in an ideal world where we
have the freedom to always do things the way we would like. I didn't mean
to imply that any of the TypeScript team or contributors are not
considering the user experience or make any kind of less intelligent
decisions than I could or would. My reply did sound pretty critical and I
apologize for that. I understand that we all have to work within the
constraints of legacy systems, standards and mindsets; even as we strive
for delivering a better experience. Throughout my 17 years designing
software, every end product has always been a slight (or sometimes
significant) bastardization of my design, always due to various
constraints. The good news is that the degree of bastardization has been
diminishing, which is a good indication of progress.
So let me take this opportunity to commend the TypeScript team for making
significant progress in helping people like me achieve our design &
development goals faster, cheaper and with significantly fewer bugs.
My comments may come across as harsh or abrasive but please know that I am
very grateful for the work that everyone in the open source community
continues to put in.
I'd rather be part of the solution than the guy standing on the sideline
complaining yet doing nothing about it. As I learn and work on
implementing my designs with these new technologies I'd like to contribute
back to the community any way I can.
Greg Dorval
greg.dorval@gmail.com
Phone: (613) 686-1508
Skype: greg.dorval
BBM PIN: 54BB8FAF
https://plus.google.com/+GregDorval https://twitter.com/gregdorval
https://twitter.com/gregdorval
http://navcanada.ca
https://twitter.com/gregdorval https://plus.google.com/+GregDorval/posts
http://ca.linkedin.com/in/gregdorval
https://mail.google.com/mail/u/0/greg.dorval
On 17 March 2015 at 11:09, Ryan Cavanaugh notifications@github.com wrote:
NoelAbrahams commentedon Mar 17, 2015
Dan Quirk (@danquirk), is anything being done about #312?
danquirk commentedon Mar 17, 2015
I don't know where it currently lies in our scheduled work but it is definitely not forgotten about. The import one in particular was the first thing I thought about when shown a demo of typing the ES6 module syntax.
NoelAbrahams commentedon Mar 17, 2015
It would be nicer to have it sooner than later - especially as people start converting from the legacy import statements to the new syntax.
[-]Request for alternative syntax to improve auto-complete experience[/-][+]Request for alternative import syntax to improve auto-complete experience[/+]