Open arun1128 opened 8 years ago
We were using it while polymer was at its very early stages and did not have enough documentation to help us with the issues we had then.
@arun1128 thanks for raising this issue here. We had many new contributors not noticing this iframe and felt frustrated while their local changes were not being reflected in the browser. I spent considerable time in explaining it to them.
@Vigneshsekar can you add this thing in readme such that it would helpful for new developers.
As we are planning to develop a style guidelines document, we shall add all required details that any new developer may require in it.
I guess for developers it is best to directly work on template.html and integrate it to project when it is done. And for loading games I guess we can give a shot to html imports, they will be deduping for us.
How about using a framework for eg AngualrJS for making it a single web page application. We can then easily load any game without using Iframe. I am working on Angualrjs fork for this project
@mohitagg1996 Angular would be good. Using phaser to implement a state for level selection might also be a good idea.
I guess angular+polymer+phaser is a very heavy stack, it would be really painful if we intend to creat hybrid apps. Moreover angular will just send ajax request anyways. Personally I feel to keep uniformity and utilize web components to its best we should try html imports.
@AgrawalAmey From a perspective of just using phaser I think implementing a state for level selection would be good, that way porting it to mobile devices and making the games responsive would be easy. But as you say and which is very true that developers might not want to use phaser and for keeping a uniformity html imports would be good.
Hi
I have been following development of this project closely for some time and would like to add some points from my side as well.
@AgrawalAmey : angular+polymer+phaser won't be heavy at all. I have used them in past and did get a very good performance out of it. You can use html import, it will be fix but not a solution. Because they are made for importing html code and here we will be trying to import html code with web components and maybe javascript, which will kill the entire performance optimisation (parallel parsing) that came with html import.
@AkshayAgarwal007 I think we should not do state selection from the phaser. Keep it separate. It's core to the application not to the game.
@Vigneshsekar I strongly feel that we should have better project management and structure ( we may use grunt). So that it's easier to build a distribution of the game. At least we should minify all the JS and CSS file. if we can't combine them.
i found a good article on web component which might help us while evaluating which direction we should go with. http://www.2ality.com/2015/08/web-component-status.html
@deepakagg For one I don't think we need a framework to manage the games, as far as loading phaser is considered repeatedly simple caching will resolve that. We can even go for service workers in case. Web components are ment to have logical functionality hence scripts are necessary. Scripts are not scoped separately for custom elements because js is primarily single threaded. Web workers can provide similar functionality but that is not the most convinent way of coding i know of. Using propr design patterns should sort any leakage issues.
@deepakagg I somewhat agree with you. Current structure is too limiting and does not adheres to DRY principle at all. For example there is pausegame function in each and every javascript file.
@AgrawalAmey I guess @deepakagg loading means evalution of javascript code by the parser every time a games load. He is not referring about the delivery of files
Anyways for managing the build process we can use https://github.com/ngbp/ngbp.
@mohitagg1996 Hi, you are correct actually I was referring the evaluation of javascript code. Sorry for the confusion.
About the management framework, Good choice I actually like it more than the yeoman.
@deepakagg That problem would persist only with iframes. html imports would not give such problem.
As per my conversation with @Vigneshsekar and my understanding of the code-base i am adding this issue here.
We can see iframe tag being used to load the games. And with HTML imports of polymer not being vulcanized, this is making too many requests. @Vigneshsekar told me that this count was about 110+ and assured to vulcanize it during/before the GSoC period. Its fine.
When i recommended the use of Iron-Ajax element to load the games, he gave me the earlier version of the code where he tried it but had a weird error. We need to restructure the code to use Ajax. Interested people can try and post the results here while i am also trying to get it resolved soon.