Greetings

Momo

I have started with the “Migrating to 2.0” guide, and that seems ok so far except for the templates…

can.EJS is no longer in core

can.EJS is no longer packaged in the core download by default. It has been replaced by can.mustache. You can use the custom download builder to replace can.mustache with can.EJS.

The custom download builder does not seem to be live anymore? How do I replace can.mustache with can.EJS?

Regards,
Francisco

import ndjsonStream from "can-ndjson-stream";

fetch( "/some/endpoint" )  // make a fetch request to a NDJSON stream service
    .then( ( response ) => {
        return ndjsonStream( response.body ); //ndjsonStream parses the response.body
    } ).then( ( exampleStream ) => {

        //retain access to the reader so that you can cancel it
        const reader = exampleStream.getReader();
        let read;

        reader.read().then( read = ( result ) => {
            if ( result.done ) {
                return;
            }
            console.log( result.value ); //logs {item:"first"}
            exampleStream.getReader().read().then( read );
        } );
    } );

The issue seems to be that the first time through, the ‘withinTemplatedSectionWithinAnElement’ flag is set to true, which will return escaped content. However, when it loops through the subsequent bound text boxes, the flag is false and will not return escaped content.

Is there a way around this?

An introductory guide to working with hooks in React

I’m having some trouble getting the build to work, but you can browse the repo or clone and run it yourself: hooks talk.

• Contact Bitovi
• Bitovi’s hiring JS devs!
• Join our Slack
• Follow us on Twitter
• Subscribe on YouTube

Links from the presenters will be posted in the comments!

const getPortSync = require('get-port-sync');

var port = getPortSync()

module.exports = function(config) {
  config.set({
    frameworks: ['mocha'],
    autoWatch: false,
    basePath: '../',
    browsers: ['Chrome'],
    port: port,
    singleRun: true,
    files: [
      { pattern: 'src/**/*.js', included: false },
      { pattern: 'src/**/*.stache', included: false },
      { pattern: 'src/**/*.less', included: false },
      { pattern: 'node_modules/steal/ext/**/*.js', included: false },
      { pattern: 'node_modules/steal-conditional/**/*.js', included: false },
      { pattern: 'node_modules/can*/**/*.js', included: false },
      { pattern: 'node_modules/mocha/**/*.js', included: false },
      { pattern: 'node_modules/chai/**/*.js', included: false },
      { pattern: 'node_modules/done-css/**/*.js', included: false },
      { pattern: 'node_modules/jquery/**/*.js', included: false },
      { pattern: 'node_modules/**/package.json', included: false },
      { pattern: 'package.json', included: false },
      'node_modules/steal/steal.js',
      'karma.bootstrap.js'
    ]
  });
};

Notice the change in steal. You can’t import it twice so once is just the extensions and the other is actually included.
Trying to debug karma.bootstrap but it looks like it doesn’t run

The goal of this post is to start a discussion, not to make any final decisions. We’ll likely do follow-up surveys and discussions and of course we’ll be user testing and looking for feedback as we start bulding things.

This post is pretty long, but not all of the ideas are really fleshed out. Feel free to skim it or skip around to things you find interesting.

Below are some ideas that I have to start the conversation, but please feel free to post whatever ideas you have to make CanJS more fun to use, better at solving problems you have, or make you more likely to recommend CanJS to other developers.

Focus on web components that integrate with any framework

With StacheElement, CanJS has a compelling solution for building web components. This sets it apart from other frameworks that might have a way to create web components using a build tool, but primarily focus on building components using framework-specific APIs and not true web components.

We could continue to build on this strength by improving the experience of building web components with CanJS. This would probably include reducing the size of StacheElement by either removing parts of stache that are used less often or completely replacing stache with another templating solution that isn’t as large. We could also build tools to make it easier to integrate our web components with popular frameworks.

Focus on the unique features of CanJS observables

The metadata built in to CanJS observables allows unique features like the dependency graph in CanJS Devtools. We should continue improving this feature, but we could also build other tools like this that are only possible because of information our observables contain. This might be tools for visualizing which data requested from the service layer is actually being used and where it is displayed in the UI. This could also be things like tools for automatically generating unit tests.

Focus on first-time Developer Experience

DoneJS allows you to scaffold out an app that uses CanJS and has generators for components, models, and other things. But many apps don’t need everything that DoneJS provides and some users are confused about the relationship between CanJS and DoneJS. We could provide a much simpler tool for scaffolding CanJS applications, a-la create-react-app.

Focus on integration with popular backend frameworks

One of the things that really helped VueJS gain popularity (at least from my outside perspective) is its close relationship with Laravel, a very popular PHP framework.

There are many other backend frameworks that don’t have “go to” JavaScript frameworks. Building tools to easily integrate with these backends and marketing to those communities could really help build the CanJS community.

Focus on making CanJS easier to learn

Over the past several years, we’ve really put a lot of focus into CanJS’s documentation, but there is a lot and it can be overwhelming for new users. We should continue to simplify canjs.com and we could also build integrations between the demos we show in our documentation and our API docs. This could allow you to build a guide step-by-step, but also see inline documentation when you hover over one of the APIs you are using.

What do you think?

These are just some ideas that I have. We might pick one and start writing up proposals and sending surveys. We might take pieces of many of them to build out a roadmap. Maybe this conversation will surface much better ideas and we’ll do none of these.

Please feel free to comment below with your thoughts on these or any other ideas you have for what the CanJS core team should be focusing on.

Thank you!

Thank you for reporting, we are taking a look at this issue, we will let know if something pops up.

The selected attribute on the option is getting set correctly but selection is not happening. see screenshot

It works

1. When I pass a serialized array of label-value pairs instead of observer array of label-value pairs
   Or
2. If we call $option.attr(“selected”, “selected”) within setTimeout with a delay of 500 it works, even with the observable array of label-value pairs

Below are screenshot of array of label-value pairs before and after upgrade

I am not sure how observe array of label-value pairs is causing selection not work

Were not sure how observable array is interfering with option selection

canjs 2.3.28 is directly compatible with jquery 3.4.1 without making any changes to application.

It messes up the “compute” part of the framework (other observables will still work).

That issue mentions a “safe” form of computes.

We could also optionally have a “safe” mode.

In modern canjs, this would more or less be wrapping this line:

with a try/catch.

I was also wondering how a unhandled exception messed up whole observe framework. Sometimes my assumption on data will be wrong and there will be unhandled undefined exceptions. In those cases I want to protect observe framework so that my whole application does not crash.

smoothlikejazz:

buildFragment

Hi @smoothlikejazz, can you give more details about what the problem is?

It would be great if you can post a CodePen (or any simplified example) with the issue.

Was the situation the following:

an error thrown that wasn’t propagated up to the console

If this is the situation, the fix is not to check for undefined everywhere.

The fix is to understand why the error was thrown that wasn’t propagated. This typically happens because promises can swallow errors if not handled properly. The fix is to make sure all errors always propagate to the console.

Current jQuery Version: v1.11.3
Need to upgrade JQuery to: v3.4.1
Our current canjs version: 2.2.5
Our current steal version: 0.11.4

1. Which version of canjs has fix for $buildFragment
   according to this post https://github.com/canjs/canjs/pull/2177 buildFragment is fixed in this version we belive, but currently still yields the error after upgrading to 2.3.28

2. Which canjs version is the best compatible version for jquery latest version of v3.4.1 which also has the smallest migration path.

Thanks in advance

How to avoid such situations? We are just checking for undefined in all cases for now.

Links:

Links from the intro:

• Bitovi Academy
• Join our Slack
• Follow us on Twitter
• Subscribe on YouTube

Links from the presenters will be posted in the comments!

the version we are using is “2.2.5”, and thanks for the suggestion currently debugging and some exceptions are thrown in jquery attempting to find elements, but still debugging and ruling out if this has any impact.

Can you turn on “break on all errors” and recreate? Is there an error that is thrown (and likely caught elsewhere)?

Has anyone run into such a case, what could make all bindings fail to trigger? What would be a starting point in trying to debug such an issue.

From what i can see is that the binding are registered properly but in this specific example the change events are not firing. i have a list of objects all with change binding and non of them are firing

• Slides
• Detailed Signaling Overview
• SDP RFC

• Slides
• jscodeshift
• can-migrate
• canjs migration docs

• Slides
• CodeSandbox Demo
• Official Suspense docs
• Official React.lazy docs

• Bitovi Academy
• Join our Slack
• Follow us on Twitter
• Subscribe on YouTube
• Community Survey

Links from the presenters will be posted in the comments!

var view = can.view("/path/to/view.stache");

In 6.0, due to the removal of NodeLists making something like this work in a memory-safe way has become a lot easier.

Here’s an example of lazyView in action: https://codepen.io/justinbmeyer/pen/bGGpWaO?editors=0010

class MyCounter extends StacheElement {
	static view = lazyView("/some/path.stache");

	static props = {
		count: 0
	};

	increment() {
		this.count++;
	}
}

I’m importing the scss file either in the .stache file, or in the app.js file.

I recently upgraded from Node 8.x to 12.x and the resulting upgrade of npm showed all the security warnings of various levels, and there were a ton of them. I found this grep command helpful to filter things down to Critical for example, work on clearing those out, then shift to showing only High level warnings:
npm audit | grep -E "(Critical)" -B3 -A10

you can also do an or/ || operator once things simmer down a bit:
npm audit | grep -E "(High || Moderate)" -B3 -A10

Made things a bit easier to manage, hope this helps someone else!

We have it on our roadmap.
We will be attempting it later this year. I will contact you at that time.

Thanks for checking up!

Regards,
Francisco

I’ll join the slack channel and review your migration guides.
I understand that Bitovi also provides consulting services?

Regards,
Francisco