Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1700] Add support for <Script> tag in View XML files

GitHub Issuen/a
TypeNew Feature
PriorityNone
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sn/a
ComponentsXML
Labelsn/a
ReporterBrenton House
AssigneeFeon Sua Xin Miao
Created2019-08-06T18:17:13.000+0000
Updated2021-01-20T13:46:47.000+0000

Description

Add support for tag in View XML files that would simply output the code from the body of the element into the auto-generated controller. Alloy PR: https://github.com/appcelerator/alloy/pull/937 Code can be added by src attribute: 
<Script src="/code/myfile.js" />
By body text: 
<Script>
// this is a test
var a = 123;
</Script>
Or by both: 
<Script src="/code/myfile.js">
// this is a test
var a = 123;
</Script>
In the last case, it will put the code from the source file above the code from the body text. The code will then be added to the auto-generated code that is put into the JavaScript controller.

Comments

  1. Ewan Harris 2019-08-07

    [~bhouse] Do you have a real world example of what this is trying to achieve? Is this similar to improvements like ALOY-744?
  2. Brenton House 2019-08-07

    [~eharris] - It might accomplish some similar things but I think they can stay as separate features. This feature is specifically for the View XML file and it allows you to inject code at any place in the processing of the XML file (beginning, end, or even in a dataCollection loop).
  3. Ewan Harris 2019-08-21

    [~bhouse], I get what the feature does. But I'm looking for actual examples and _why_ we should add this. I'm not convinced authoring JS inside Alloy XML tags is a great DX, I like the idea of referencing a file though. Edit: I just wanted to add why I think that allowing embedded code isn't a great DX. If you're writing JS in a XML file, Studio nor the editor plugins will highlight the correctly, sure we can add it to the 3 things, but knowing the context there it's easier said then done. Additionally, including this into the debugging experience will require some work. Our sourcemaps for Alloy are already a bit of a minefield, including another file (which is XML) only makes that more complex, and requires more logic by the debuggers to correctly resolve things. I think we will have to solve this for the file reference solution too. Again both of those problems I outlined are possible to do, but I don't think the value of embedded code is worth the cost of them (and there's probably some more integration points I'm missing)
  4. Ewan Harris 2020-01-24

    [~bhouse] just bumping my last comment. Any thoughts?
  5. Brenton House 2020-01-24

    Thanks! Let me check some of the apps that use this feature and see how debugging works using the new syntax.
  6. Brenton House 2020-01-24

    [~eharris] - How does debugging work with and XML view currently since all the XML is written as JavaScript during compile? Seems like that would be a similar issue?
  7. Brenton House 2020-01-24

    I just ran a test using this in index.xml: 
       	<script>
   		console.error('you are here in index.xml');
   		debugger;
   	</script>
    The debugger seemed to work fine and dropped me in here where I would expect: 
       // Generated UI code
     console.error('you are here in index.xml');
     debugger;
   
     $.__views["index"] && $.addTopLevelView($.__views["index"]);
     $.__views["index"] = Ti.UI.createWindow(
     { backgroundColor: "red", top: 100, id: "index" });
  8. Ewan Harris 2020-01-24

    Currently there is nothing to debug in an XML view, the only thing we have to worry about exposing the controller code to the debugger. My concern here is the complication of trying to generate a sourcemap that is a combination of that the xml file and the js file. Handling mapping that back to the file in Studio/VS Code/Chrome/Safari) etc. We could just say "oh you can't debug that code, put it in a controller and you can", but honestly I'd rather not add a feature than compromise on the developer experience we offer.
  9. Brenton House 2020-01-24

  10. Ewan Harris 2020-01-24

    I meant people don't directly debug in XML (i.e. set breakpoints on lines in the XML file, step through etc.). I get that the compiled code is a useful escape hatch for people to use when stumped, but we shouldn't be promoting working in compiled code. If you use Alloy, you understand that the XML, JavaScript, and TSS files get merged into one JavaScript file at compile time., most people do, but first time users/people who don't care to dive in fully might not. We can't make those assumptions
  11. Jan Vennemann 2020-03-05

    I was just looking through all my GitHub notifications and stumbled upon this. I have to agree with Ewan here and don't immediately see the value in this new tag. You mentioned that it allows you to inject code anywhere during the XML view processing. It would be great if you can outline some use-cases where this is necessary so we get an idea why you need to do that. Just being able to randomly inject JavaScript in views feels kinda hacky and IMHO is against the whole view/controller concept that Alloy uses.
  12. Brenton House 2020-03-06

    I know! JavaScript and XML together! In the same file no less! It's crazy! Just like those like those crazy other frameworks like Vue and React or even HTML :D
  13. Jan Vennemann 2020-03-06

    All those frameworks have a clear seperation between template and component code. You don't add a script tag to the template to mix in some vanilla JS. That's not how they work at all. What you are doing is basically the HTML script tag. In all those framework that would be executed during runtime in the browser, without any scope to the component. What you are doing is injecting JS code during compile time. That's something totally different, and AFAIK, none of those frameworks supports that. Just to be clear, i'm sure that there is some missing piece in Alloy that is the motivation for this. I'm just not convinced that a script tag that allows injecting code somewhere in the view is the proper solution. So again, some examples where this is necessary would be great to see what the actual problem is.
  14. Brenton House 2020-03-06

    The purpose of this, like most of the PRs I create, is to speed up coding time (as opposed to compile time). From what I've seen, coding usually takes a significant higher percentage of a developer's day than compiling so that is usually where I direct my efforts. I understand if you can't merge it. I am usually able to find another home for my PRs so that they can live a long and prosperous life in a parallel universe somewhere :D
  15. Jan Vennemann 2020-03-09

    {quote}The purpose of this, like most of the PRs I create, is to speed up coding time (as opposed to compile time). From what I've seen, coding usually takes a significant higher percentage of a developer's day than compiling so that is usually where I direct my efforts.{quote} I get that this is meant to improve developer experience, but again, do you have a real world example where this would be useful? I'm just trying to understand what specific problem you are trying to solve with this. The examples you posted are very simple and don't really explain why such a feature would be necessary. {quote}I understand if you can't merge it. I am usually able to find another home for my PRs so that they can live a long and prosperous life in a parallel universe somewhere {quote} That's cool and all, but i would rather see us work together on Alloy instead of you just doing you own thing with Turbo. Some of your improvements made in Turbo were already merged back to Alloy. Some of them should better bet integrated into the SDK. Some of them need some evaluation/improvements before they can go into Alloy. Same for this PR. Ewan and I are not trying to shut your idea down per se, we are trying to understand what's the actual problem is, and if there may be a solution that fit's better into Alloys design principles.
  16. Rene Pot 2021-01-20

    We already support injecting JavaScript inside xml tags. We have a <Module> tag for that, which can return anything UI based you want with any complexity you want, and can call any lib file.
  17. Brenton House 2021-01-20

    The script tag is much more than this. It doesn’t require you to return anything. Plus, any variables you set in that block are in scope for use within the rest of the view.

JSON Source