Is htmlbool types no longer supported in 4.x? like where I could have an attribute
active if set becomes true? The warnings in 3.x seem to indicate this should now be active:from="true"
btw @frank-dspeed I found the part of code that is causing the error from yesterday: It looks like this:
{{#if(isSaving)}}
<div class="loading"></div>
{{else}}
<can-slot this:from="this" name="submit">
<div class="btn-group" role="group" aria-label="Form Buttons">
<button type="button" class="btn btn-primary" on:el:click="dispatchEvent('submit')">
<i class="fa fa-floppy-o"></i> Submit</button>
<button type="button" class="btn btn-primary" on:el:click="dispatchEvent('cancel')">
<i class="fa fa-ban"></i> Cancel</button>
</div>
</can-slot>
{{/if}}
when isSaving gets set to true, the error occurs.
Here's the actual error trace: https://gist.github.com/roemhildtg/bee7fc1d34e8bc2e4dbeb45d649d346c
can-stache-bindings.js:257- can-slot element, attributeListener is undefined, which eventually causes the error
@roemhildtg 'htmlbool' still exists. We do still warn about
{{#if active}}active="active"{{/if}} forms for component tags but that is meant to discourage using the form for passing string values to components.
I think this has been overlooked in the 3->4 process, that stache bindings can set element attribute values using
el:some-attr:from="vmProp" forms but not add and remove the attribute based on truthiness.
Probably a good step for can-stache-bindings is to add
:if as a binding
so
el:active:if="active" would set the attribute if active was true in the parent scope.
but not add and remove the attribute based on truthiness
@bmomberger-bitovi why do you need bindings for that?
I think what we all want is for can-log to STFU.
The question is how.
that warning should only be displayed if
active is a property on the viewModel
which is what is actually deprecated and removed in 4.0
Okay, I misspoke. The htmlbool type works as expected. It was the case where active="true" I think.
So that error above, it seems like the
can-slot element is not getting an attributeListener assigned, but when the element is removed, it looks like can-stache-bindings is trying to remove the undefined attributeListener. Does it sound like I'm on the right track here?
in bitballs its updated
you can look into it at any time :D
currentActive is a property now
does some one know how to debug such errors
Potentially unhandled rejection [4] renderInZone/zonePromise<@http://localhost:8080/src/index.stache:241:17
anonymous/</exports.then/</callback<@http://localhost:8080/node_modules/can-zone/lib/tasks.js:150:12
anonymous/</Task.prototype.run@http://localhost:8080/node_modules/can-zone/lib/zone.js:42:9
anonymous/</Zone.prototype.runTask@http://localhost:8080/node_modules/can-zone/lib/zone.js:184:9
anonymous/</Zone.prototype.waitFor/<@http://localhost:8080/node_modules/can-zone/lib/zone.js:285:10
wrapped@http://localhost:8080/node_modules/can-zone/lib/zones/debug.js:50:17
callWith/<@http://localhost:8080/node_modules/can-zone/lib/tasks.js:161:12
tryCatchReject@http://localhost:8080/node_modules/steal/steal.js:1183:28
runContinuation1@http://localhost:8080/node_modules/steal/steal.js:1142:4
makePromise/Rejected.prototype.when@http://localhost:8080/node_modules/steal/steal.js:963:4
makePromise/Pending.prototype.run@http://localhost:8080/node_modules/steal/steal.js:821:5
[3]</</</Scheduler.prototype._drain@http://localhost:8080/node_modules/steal/steal.js:97:4
Scheduler/this.drain@http://localhost:8080/node_modules/steal/steal.js:62:4
run@http://localhost:8080/node_modules/steal/steal.js:268:4
steal.js:140:22
unhandledRejection/logError<
http://localhost:8080/node_modules/steal/steal.js:140:22
report
http://localhost:8080/node_modules/steal/steal.js:167:5
flush
http://localhost:8080/node_modules/steal/steal.js:189:5
i always have something that fails in zone but i never get to the point where that is
I think you gotta set a breakpoint in the tasks.js, then figure out what is causing the error by tracing up the stack
its a steal file or what?
I don't really have a great answer though. I've struggled with that myself a bunch. My situation was dealing with socket.io
did you got this break point stuff in can4 working?
afaik
Ran into issues with can-util
ah do you want a can-util
compatible version?
for migration i have one wait
it was a fail befor
if you install now fresh it should be fixed
maybe more easy fix is
simply install my compat version
as this can happen on many places
simply npm install https://github.com/frank-dspeed/can-util --save
till you upgraded all done-ssr and can packages via
npm outdated
to the latest versions
which can take some time
this can-util version uses can-dome-data-state latest
so you don't get this warnings and that
:D
since it will break canjs 3.0 apps
and simply pin olders down to 3.xx
i see no problem with that at all
but this can-util version helps migrating
and getting things up fast
so no problem
when all is up to date simply can-util@latest and all is as it should be
so no pain i did the same flow
arn't working as expected out of the box
i get no autorender-breakpoints :(
updating donejs to work with canjs 4.0 is still in progress
i see no open issues
it works i am using ssr all
and there's a conflict with multiple versions
but nothing in canjs 4.0 should be importing
can-util/dom/*
so nothing should be importing that version of
can-dom-data-state
the new done-ssr does not
since some hours or 1 day
so now all is working without my git magic
:D
@phillipskevin i did supply my working version as update to the generator
Hmm, So I'm pretty sure I clean installed everything and I'm NOT using done-ssr in a project but I'm getting
steal.js:7390 Error: Error loading "can-component@4.0.0#can-component" at http://192.168.9.83:8081/node_modules/can-component/can-component.js
Error loading "can-component@4.0.0#can-component" from "spectre-canjs@1.0.1#index" at http://192.168.9.83:8081/index.js
Did not find ./node_modules/can-dom-data-state/package.json
Unable to find a compatible version of can-dom-data-state
Wanted: ^1.0.0
Found: 0.2.0
@roemhildtg delete package-lock delete node_modules
it's a direct dependency of can-component: https://github.com/canjs/can-component/blob/master/package.json#L44
is outdated i think
you can also run
npm ls --depth=0 and it will give you scary warnings if dependencies are missing
but it was anyway needed
the old app stoped working got to big to undebug able
to much time presure
so i choosed to directly migrate because of better errors
:D
at some places it helped!
+-- can-component@4.0.1
| +-- can-dom-data-state@1.0.1
| `-- can-stache-bindings@4.0.3
| `-- can-dom-data-state@1.0.1
+-- can-connect@2.0.1
| `-- can-view-import@4.0.1
| `-- can-dom-data-state@1.0.1
+-- can-stache@4.0.2
| `-- can-dom-data-state@1.0.1
`-- can-util@3.11.2
+-- can-dom-data-state@0.2.0
+-- can-event-dom-enter@1.0.4
| `-- can-dom-data-state@0.2.0 deduped
`-- can-event-dom-radiochange@1.0.5
`-- can-dom-data-state@0.2.0 deduped
are you seeing an error with multiple versions of
can-dom-data-state?
in the browser console, look at
System._traceData.parentMap
an-dom-data-state@0.2.0#can-dom-data-state:
can-util@3.11.2#dom/data/data
:
true
can-util@3.11.2#dom/mutation-observer/document/document
:
true
can-util@3.11.2#js/cid/get-cid
:
true
to see what in your app is loading those things
can-util/dom/data
also in your project
then you know the package that references it wrong
but also simply run npm outdated
and look if all is latest
then this shouldn't happen
can-connect-feathers 4.0.0-pre.2 4.0.0-pre.2 3.7.1 applications
can-define-backup 1.0.0-pre.1 1.0.0-pre.1 0.0.1 applications
can-util 3.11.2 git git applications
done-autorender 2.0.0-pre.11 2.0.0-pre.11 1.5.2 applications
done-component 2.0.0-pre.1 2.0.0-pre.1 1.0.1 applications
done-serve 2.0.0-pre.0 2.0.0-pre.0 1.5.0 applications
like a 1.0.0 of
can-define-backup hasn't been published
ya
that works
with the pre version
i posted about that on the wip issue
thank you for doing that
feathers and define-backup is left but we can use pre versions
they are working for me
but there are other ecosystem things that don't have pres even
they arn't importent
lol
but i want to use can-migrate
need to recode that complet
:D
instead of rewriting the whole thing
Alrighty, I'll look into this more tomorrow. Thanks guys!
because its fail by design needs to get rewriten using streams
it errors because to many args
over 2500 000
so
:D
wait
**/*
only that works
maybe project to big files to big
i looked into the code for me it was a horror i do a lot of file processing devops tasks
i have big projects
:D
ah thats not cool
then i got wrong instructions
:D
how would you run can migrate against the src folder?
fyi, there is a new version of can-migrate out
can-migrate@2
which has the transforms for canjs 3 -> 4
at present it looks like looping forever
All done spawn workers
i am not sure what it does
now it finished
i think it did nothing
always unmodifyed
0 OK
no but i expect it tells me all OK
at present the syntax should be well i expect it well
but did it manual
Time elapsed: 0.415seconds
Processing 2 files...
Spawning 2 workers...
Sending 1 files to free worker...
Sending 1 files to free worker...
All done.
Results:
0 errors
2 unmodified
0 skipped
0 ok
it loops like this
and then after a long time stops
yes... so there are 2 js files in your src directory
and nothing was changed
like that with always 2 files
and in the src directory in sub directorys
are many files
:D
i get errors
that helps thats what i expected
it shows me where i got typos
but I'm glad it's working
so it don't floods the console
and simply after end displays a result
:D
and i need to do that for stache also or not?
why i am doing only *.js?
to not flood the console
you can do
src/**/* if you want all the files in your src directory
:D
**/*
throws
{ Error: spawn E2BIG
at _errnoException (util.js:1003:13)
at ChildProcess.spawn (internal/child_process.js:340:11)
at Object.exports.spawn (child_process.js:499:9)
at module.exports (/usr/local/lib/node_modules/can-migrate/node_modules/execa/index.js:201:26)
at series (/usr/local/lib/node_modules/can-migrate/bin/can-migrate.js:132:12)
at /usr/local/lib/node_modules/can-migrate/node_modules/promise-map-series/index.js:11:14
at tryCatch (/usr/local/lib/node_modules/can-migrate/node_modules/rsvp/dist/rsvp.js:525:12)
at invokeCallback (/usr/local/lib/node_modules/can-migrate/node_modules/rsvp/dist/rsvp.js:538:13)
at publish (/usr/local/lib/node_modules/can-migrate/node_modules/rsvp/dist/rsvp.js:508:7)
at flush (/usr/local/lib/node_modules/can-migrate/node_modules/rsvp/dist/rsvp.js:2415:5) errno: 'E2BIG', code: 'E2BIG', syscall: 'spawn' }
thats why i recode it
E2BIG isn't acepptable
out of my engineering view
E2BIG means over 2,6 million args
to the spawn process
no node modules my frind
src has only modlets
any way this should never depend on args
and spawn and all that
i make it a single node process stream
no spawn magic
constant ram and mem usage
also needed on servers with less cpu ram
inside a .component file
damn
this .component files are killing me maybe they are the root of all evil
promises that don't resolve
when i have types in them they fail with a to general error :)
i think they are evil i will replace them as fast as possible
it now first time renders with can-zone
in done-component
ah your right
its done-component that loads .component files
tricky :)
evil done-component not component files :) but in general i understand that this will not get easy fix able
component files should get deprecated because they lead to parsing errors and all that
and not good debug able even with optimizing that done-component