Hi. Firstly, Thanks for this project.
When I try to optimize my JavaScript codes, I got an error
not an object
TypeError
at repl:1:12
My code is below
var date = document.querySelector("#date")
var dateSet = document.querySelector("#dateSet")
var dateim = new Dateim()
dateim
.date('31/12/2017')
.format('mm-dd-yyyy')
.when({
evt: 'click',
sel: dateSet,
method: function() {
date.innerText = dateim.parsed
}
})
.settings({
lang: {
month: [
'Ocak', '艦ubat', 'Mart', 'Nisan', 'May谋s',
'Haziran', 'Temmuz', 'A臒ustos', 'Eyl眉l',
'Ekim', 'Kas谋m', 'Aral谋k'
]
}
})
.run()
isn't is true my code?
See #542 and #24.
@deltaidea Yes, I saw these issue topics. But, I have no idea, why prepack need to knowledge about DOM? I think I will solve this problem myself.
Also, it worked dateim.js file except let.
https://github.com/facebook/prepack/issues/515#issuecomment-298996381
Thanks :)
What I mean but that is not implementation details or semantics of DOM. Instead, I mean just the signatures of all relevant methods, types of values, as well as the fact that changing stuff in DOM has implications outside of the JS context.
const foo = getFoo();
foo.innerText = "Hello world";
This code is either useless or not, depending on the implementation of getFoo.
It's useless if it's const getFoo = () => ({}) and both lines can be eliminated without changing the outcome (nothing happens).
This code might also result in an exception if getFoo is not defined at runtime. Then there's no point in keeping the second line as it is unreachable.
Another example is just for (let i = 0; i < 10; i++) { foo; }. Seems unnecessary, so let's remove it, right? Wrong, because you can never be sure that window.foo doesn't have a getter that makes an AJAX request.
This is not even an obscure edge case, popular libraries do this. Mocha had been doing this for a long time with its .should interface. A getter would throw an exception depending on other stuff and fail the unit test.
If that sounds dumb, then your statement date.innerText = dateim.parsed should also be considered free from side-effects because date.innerText isn't used anywhere else and therefore can be removed.
The whole point of Prepack is to analyze source code and pre-execute as much as possible. If it can't make assumptions about types and signatures, it won't optimize anything because each expression might have side effects that are obvious to the user but not to Prepack.
DOM definitions would allow to compile document.createElement("div").tagName.length to just 3, ideally.
This tool is not ready for production. It is still in development. Subscribe to #24 and wait.
@deltaidea Thank you for your explanation.
Now I understand. I will try contribute this project when i understand fully.
Thanks again.
Thank you for your interest! 馃憤 I'm just another user, happy to help. This is an interesting project.
Closing as the question got answered.
Most helpful comment
What I mean but that is not implementation details or semantics of DOM. Instead, I mean just the signatures of all relevant methods, types of values, as well as the fact that changing stuff in DOM has implications outside of the JS context.
This code is either useless or not, depending on the implementation of
getFoo.It's useless if it's
const getFoo = () => ({})and both lines can be eliminated without changing the outcome (nothing happens).This code might also result in an exception if
getFoois not defined at runtime. Then there's no point in keeping the second line as it is unreachable.Another example is just
for (let i = 0; i < 10; i++) { foo; }. Seems unnecessary, so let's remove it, right? Wrong, because you can never be sure thatwindow.foodoesn't have a getter that makes an AJAX request.This is not even an obscure edge case, popular libraries do this. Mocha had been doing this for a long time with its
.shouldinterface. A getter would throw an exception depending on other stuff and fail the unit test.If that sounds dumb, then your statement
date.innerText = dateim.parsedshould also be considered free from side-effects becausedate.innerTextisn't used anywhere else and therefore can be removed.The whole point of Prepack is to analyze source code and pre-execute as much as possible. If it can't make assumptions about types and signatures, it won't optimize anything because each expression might have side effects that are obvious to the user but not to Prepack.
DOM definitions would allow to compile
document.createElement("div").tagName.lengthto just3, ideally.This tool is not ready for production. It is still in development. Subscribe to #24 and wait.