| Re: [wtp-dev] JSDT weekly 20151006 |
|
A quick question with probably not a quick answer. Does Tern support _javascript_ variants? In particular I'm thinking of JSX with React. And that is also interesting in the React
Native space. This is similar to QML for Qt.
Doug
From: wtp-dev-bounces@xxxxxxxxxxx [wtp-dev-bounces@xxxxxxxxxxx] on behalf of Mickael Istria [mistria@xxxxxxxxxx]
Sent: Thursday, October 08, 2015 10:27 AM To: wtp-dev@xxxxxxxxxxx Subject: Re: [wtp-dev] JSDT weekly 20151006 On 10/07/2015 09:53 AM, Angelo zerr wrote:
On this topic, I suggest the following changes in JSDT that I find as working enough for my experiments regarding merging Tern Outline into JSDT Outline: * Remove some extension points that are covered by upstream frameworks. Mainly the Common Navigator, which makes it easy to write an extensible Outline or a Quick Outline, without need to add other extension points. For example, the "_javascript_ElementFilter" extension point could be replaced by usage of the commonFilter. This is not a critical issue for extensibility, but removing code in JSDT without loosing funcitonality nor extensibility is something that we'll all see as a good thing. * Take advantage of adapters: in most classes where we want to have extensibility, JSDT directly uses or casts to its types (IJavaScriptType, IJavaScriptUnit, IJavaScriptElement...). Extenders projects may not use directly these types but might be able to adapt to the specified types relying on the Core adapter framework. By leveraging that and checking for adapters when possible, several pieces of JSDT code would remain working with the parts of extending frameworks. Current JSDT Outline filters are an example: Tern can provide its own richer elements to Outline, but since they're not JSDT types, filters don't work. Assuming JSDT would check for adapters and Tern would provide adapters, filters would remain working even with Tern content. We can imagine similar thing for refactorings, search and others. |