Prepack: not an object When I using REPL

Created on 4 May 2017  路  6Comments  路  Source: facebook/prepack

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?

question

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.

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.

All 6 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

NTillmann picture NTillmann  路  4Comments

jtenner picture jtenner  路  5Comments

MichaelBlume picture MichaelBlume  路  6Comments

kamranahmedse picture kamranahmedse  路  7Comments

sandipp picture sandipp  路  4Comments