Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-25536] TiAPI: Deprecate Ti global namespace, move to require/import based API's

GitHub Issuen/a
TypeImprovement
PriorityHigh
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sn/a
ComponentsAndroid, iOS, Windows
Labelsroadmap2019
ReporterHans Knöchel
AssigneeGary Mathews
Created2017-11-19T23:39:54.000+0000
Updated2021-02-08T18:58:39.000+0000

Description

*Motivation* As we are moving forward to support more ES6 sugar in Titanium, the legacy namespace-based API's have served well but need to be replaced by a more modern approach. *Challenges* We have to think about both the core and native modules and validate whether this actually needs to be a breaking change for modules, as most of the work will be done in the require-handling and kroll-invocation. *Example* Before: 
const window = Ti.UI.createWindow({
  title: 'So legacy ...'
});
After: 
import { Window } from 'titanium-core';
// OR: import { Window } from 'titanium-ui';

var window = new Window({
  title: 'Beautiful new API!'
});
*Roadmap* If possible, we could introduce a require/import based approach for one of the next feature-versions, deprecate in the next major (8.0.0) and remove in the following major (9.0.0). *EDIT*: [~gmathews] did [Ti.ES6](https://github.com/appcelerator/ti.es6) earlier this year, which uses a similar approach, but requires a lot of "metabase"-like files in order to work.

Comments

  1. Chris Barber 2018-02-02

    Typing "titanium-" is going to get repetitive. I don't even think we need to namespace since importing a module without a relative path will imply trying to load a built-in module (before scanning "node_modules"). 
       import { Window } from 'ui';
    We could also support something like this: 
       import TextField, { INPUT_BORDERSTYLE_ROUNDED } from 'ui/text-field';
  2. Hans Knöchel 2018-02-03

    Maybe 
       import { Window, Label, View } from { titanium };
    I heard "some other frameworks" do it that way :P.
  3. Chris Barber 2018-02-05

    I'm not certain I've ever seen that syntax. I don't see how that's an improvement on the above examples.
  4. Hans Knöchel 2018-02-05

    I feel like it might be confusing to not prefix the imports as there are many (especially classic apps where we used to recommend a /ui/common etc require style. But if you work more on Node than I do, so I'd trust your opinion.
  5. Hans Knöchel 2018-08-08

    [~cwilliams] Any thoughts on the import-design here? You worked on some similar approaches for the Hyperloop ES6 namespaces already, so you might have an idea. My latest proposal would be a mix of [~cbarber]'s approach and my initial one: 
       // Resolved internally to Ti.UI.TextField, Ti.UI.Button and Ti.UI.INPUT_BORDERSTYLE_ROUNDED
   // Note: INPUT_BORDERSTYLE_ROUNDED lives under Ti.UI, not Ti.UI.TextField
   import TextField, Button, { INPUT_BORDERSTYLE_ROUNDED } from 'titanium/ui';
    That way, we could pretty much write a regex to map require-statements prefixed with titanium to look at the core-modules.
  6. Chris Barber 2018-08-08

    Again, typing "titanium-" is going to be repetitive. Secondly, we don't want a "core" module that exports the entire API. I'd be fine with a specific silo (e.g. ui, fs, etc). Just note that when "ui" exports all UI classes, it adds overhead and yet another place a class need to be registered/exported. In my opinion, the following is how it should be: 
       import Window from 'ti/ui/window';
   //  or import { Window } from 'ti/ui';
   
   const window = new Window({
     title: 'Beautiful new API!'
   });
  7. Hans Knöchel 2018-08-08

    So you are complaining about titanium vs ti? I did not propose titanium- in the latest proposals.
  8. Chris Barber 2018-08-08

    Also, import implies it's loading a JavaScript module which is different than a CommonJS module. JavaScript module exports MUST be static and are loaded async. CommonJS module exports can be dynamic and are loaded sync. Node is solving this problem by introducing the .mjs file extension so that the loader can determine what it's loading. How are you planning to support this? If we continue to use Babel to transform modules, then we'll be OK since it wraps all exports of every file. However, this would be a crutch and eventually we would get rid of Babel and natively support JavaScript modules and we'll have a big problem.
  9. Chris Barber 2018-08-08

    Yes, I'm saying we shouldn't make people type "titanium-" everywhere as the description in this issue currently suggests.
  10. Christopher Williams 2019-02-26

    Note that I think Gary has made some real nice progress on this general idea in his ti.es6 project here: https://github.com/appcelerator/ti.es6

JSON Source