glimmerjs/glimmer-application

[MOVED] This package is now part of the Glimmer.js monorepo

glimmer-application's Issues

`@tracked('args')` in component nested within a `{{#each}}` seem to invalidate with old values

I'm seeing old values for this.args in a component nested within an {{#each}}. I've included two identical simple applications below.

The first works fine and is running on glimmer-playground.netlify.com which, at time of writing, has a dependency on @glimmer/application 0.6.0:

• Sample application running @glimmer/application 0.6.0

The second seems to exhibit the bug, it's running on this fork which has updated to @glimmer/application 0.7.0:

• Sample application running @glimmer/application 0.7.0

Tracked property on a service doesn't invalidate tag

A reproduction appropriate for http://glimmer-playground.netlify.com/.

<div>
  <h1>Welcome to Glimmer!</h1>
  <p>You have clicked the button {{count}} times.</p>
  <button onclick={{action increment}}>Click</button>
  <br>
  Service#isMax: {{service.isMax}}
  <br>
  Component#isMax {{isMax}}
</div>

import Component, { tracked } from '@glimmer/component';

class Service {
  @tracked
  isMax = false;
}

export default class extends Component {

  constructor(options) {
    super(options);
    this.service = new Service();
  }

  @tracked count = 1;
  
  increment() {
    this.count++;
    if (this.count > 2) {
      this.service.isMax = true;
    }
  }

  @tracked('service.isMax')
  get isMax() {
    return this.service.isMax;
  }
}

Expected: Both {{service.isMax}} and {{isMax}} will toggle to true after passing a count of 2.

Action: Only isMax toggles to true.

userland files

Not sure if this is an undocumented requirement or a feature still in progress, but userland files break the build.

If an unexpected file is found outside of src/ui or src/utils, the build bails out.

$ ember -v
ember-cli: 2.14.0-beta.1
node: 6.9.2
os: darwin x64

$ ember new my-app -b @glimmer/blueprint
...

$ cd my-app
$ vim src/data.ts
...

// src/data.ts
export default {
  foo: "bar"
}

$ ember s
Livereload server on http://localhost:49153
The Broccoli Plugin: [ResolutionMapBuilder] failed with:
Error: The type of module 'data' could not be identified
    at module.exports (/Users/noslouch/projects/my-app/node_modules/@glimmer/resolution-map-builder/lib/get-module-specifier.js:72:15)
    at mappedPaths.forEach.modulePath (/Users/noslouch/projects/my-app/node_modules/@glimmer/resolution-map-builder/lib/index.js:124:21)
    at Array.forEach (native)
    at ResolutionMapBuilder.build (/Users/noslouch/projects/my-app/node_modules/@glimmer/resolution-map-builder/lib/index.js:120:15)
    at /Users/noslouch/projects/my-app/node_modules/broccoli-plugin/read_compat.js:93:34
    at tryCatch (/Users/noslouch/projects/my-app/node_modules/rsvp/dist/rsvp.js:539:12)
    at invokeCallback (/Users/noslouch/projects/my-app/node_modules/rsvp/dist/rsvp.js:554:13)
    at publish (/Users/noslouch/projects/my-app/node_modules/rsvp/dist/rsvp.js:522:7)
    at flush (/Users/noslouch/projects/my-app/node_modules/rsvp/dist/rsvp.js:2414:5)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)

The broccoli plugin was instantiated at:
    at ResolutionMapBuilder.Plugin (/Users/noslouch/projects/my-app/node_modules/broccoli-plugin/index.js:7:31)
    at new ResolutionMapBuilder (/Users/noslouch/projects/my-app/node_modules/@glimmer/resolution-map-builder/lib/index.js:60:10)
    at GlimmerApp.buildResolutionMap (/Users/noslouch/projects/my-app/node_modules/@glimmer/application-pipeline/dist/lib/broccoli/glimmer-app.js:267:16)
    at GlimmerApp.buildConfigTree (/Users/noslouch/projects/my-app/node_modules/@glimmer/application-pipeline/dist/lib/broccoli/glimmer-app.js:260:30)
    at GlimmerApp.javascript (/Users/noslouch/projects/my-app/node_modules/@glimmer/application-pipeline/dist/lib/broccoli/glimmer-app.js:181:31)
    at GlimmerApp.toTree (/Users/noslouch/projects/my-app/node_modules/@glimmer/application-pipeline/dist/lib/broccoli/glimmer-app.js:228:27)
    at module.exports (/Users/noslouch/projects/my-app/ember-cli-build.js:23:14)
    at Builder.setupBroccoliBuilder (/Users/noslouch/projects/my-app/node_modules/ember-cli/lib/models/builder.js:56:19)
    at new Builder (/Users/noslouch/projects/my-app/node_modules/ember-cli/lib/models/builder.js:30:10)
    at ServeTask.run (/Users/noslouch/projects/my-app/node_modules/ember-cli/lib/tasks/serve.js:24:55)

But if I make a src/utils directory and move in my userland file, it works.

$ mkdir src/utils
$ mv src/data src/utils
$ ember s
// success

Things That Need To Be Fixed

This is an ongoing list of stuff that I'm finding that have discovered in trying to work on this.

Build

• No confidence in types at build/publish time
• Build seems pretty slow for the amount of files
• Extract GlimmerTemplateCompiler
• le sourcemaps

Test Suite

• Test suite should have more exhaustive rendering tests, similar to Ember's
• ember serve should run the tests
• Unclear how to test end-to-end typical application with Component and @tracked
• Tests don't update

Disallow dotted helpers/modifiers

Once glimmerjs/glimmer-vm#402 lands we'll need to update Environment#hasComponentDefinition and Environment#getComponentDefinition not to receive a string[] as a component name but rather a string.

Establish convention for calling registerComponentManager

From a comment by @robbiepitts:

What does the intended usage of registerComponentManager look like? The Environment class is imported in application.ts and registered manually in Application#initialize (which is ultimately called from the constructor). Then when Application#boot happens the container is set up, Application#env is assigned, and the app is rendered. This all means that, as far as I can tell, we cannot registerComponentManager before Application is instantiated, after it is instantiated and before boot, or after boot.

Also wondering if it would make sense to incorporate component managers into the DI system? Then we can just look them up and don't have to worry about registering.

each helper attempts to render extraneous components

After applying #8, each loops that render components are rendering an extra iteration and throwing an error.

Helper runs every few milliseconds after a tracked property changes

I've setup a minimal reproduction here:
https://github.com/topaxi/glimmer-helper-rerendering-issue

The helper itself has nothing to do with the interval and only has static input.

nested each causes endless rerender

If I have nested each helpers like so:

{{#each grid key="@index" as |gridRow|}}
  {{#each gridRow key="@index" as |gridItem|}}
    <grid-item />
  {{/each}}
{{/each}}

I can see endless re-renders in the timeline. Not sure if this is WAI.

Maybe it can happen with single each as well. (cc @GavinJoyce)

Simple reproduction repo is here: https://github.com/MartinMalinda/glimmer-endless-render

Ergonomics / Polish / Initial Experience "Punch List"

• Can't use async function out of the box due missing regeneratorRuntime (#55)
• Sourcemaps seem broken (#56)
• Integration with npm packages should be documented and/or improved (#57)
• Guides need a quick (optional) introduction to TypeScript and pointers to other resources. (glimmerjs/glimmer-website#65)
• Guides need to document args vs. attrs (and more generally, templates!) (glimmerjs/glimmer-website#66)
• Nested components are broken (#84)

This issue is not intended to supersede #54, which is largely focused on technical and internal issues.

Can't use `async` / `await` out of the box

This is currently due to missing regeneratorRuntime.

Sourcemaps seem to have issues

A number of people have reported problems with source maps, and many contributors have experienced the problem.

If you experience issues, please reply to this issue with more information. The more the better at this point.

Infinite loop when observing 'args' in a computed property that returns an array that is iterated over by {{#each}}

import Component, {tracked} from "@glimmer/component";
export default class MyComponent extends Component {
    @tracked('args') get arrayTest() {
        console.log('bye');
        return [1, 2];
    }
};

<div>
    {{#each arrayTest key='@index' as |num|}}
         {{num}}
    {{/each}}
</div>

With the above component, and template, the computed property gets recomputed in an infinite loop. You'll see bye in the console forever.

If you remove {{num}} from the inside of the {{#each}}, the infinite loop does not happen.

Poor error handling when a template can't be found

We get an unhelpful error message ("Cannot read property 'split' of undefined") and a stack trace that does not make obvious the problem. The real issue is that we continue along with a failed specifier identification.

Main component JS ignored

Tried adding a backing js component to the main component. It seems to be ignored. I'm guessing the component needs to be created in application.render()?

Repro hello-world branch: https://github.com/asakusuma/hello-glimmer/tree/main-component-bug

Warning when running `ember build` with `--web-component` apps

When creating a Glimmer app with --web-component the ember build step throws the following warning.

/src/index.ts(21,26): Argument of type 'App' is not assignable to parameter of type 'Application'.
  Types of property 'env' are incompatible.
    Type 'Environment' is not assignable to type 'Environment'. Two different types with this name exist, but they are unrelated.
      Types have separate declarations of a private property 'helpers'.

After some cursory research with @robbiepitts it seems like the issue is that both @glimmer/component and @glimmer/web-component include @glimmer/application resulting in multiple instances of Application and Environment.

To be clear the app still builds and functions. In dev mode (i.e. when using ember serve) the warning is not present.

At first Robbie thought it might be an issue of version mismatch between the main package.json and the package.json files for @glimmer/component and @glimmer/web-component. Currently both of them request version 0.3.x and the main package installs 0.4.0. Updating both packages to request 0.4.0 didn't solve the issue.

Docs lacking: how do I use Glimmer as a view layer for my app?

I've been looking for a good component library that isn't React. Glimmer tickles me in all the right places, but I cannot figure out how to just require it instead of bringing the ember-cli and the rest of the jungle along.

Is that something that is possible? Is it documented anywhere? I'm guessing it should be in the docs for this and probably the original site too.

Can't create new glimmer app - Unknown blueprint

I followed the instructions on the website but got stuck at the step of creating a new application:

$ ember new glimmer-stars -b @glimmer/blueprint
Unknown blueprint: @glimmer/blueprint

I tried using the full repo URL for the blueprint (https://github.com/glimmerjs/glimmer-application.git, not sure if that's the right one), but then received another error:

$ ember new glimmer-stars -b https://github.com/glimmerjs/glimmer-application.git
installing ember-cli117231-19812-1s8ldo3.i968lx47vi
WARNING: Skipping npm install: package.json not found
Error creating new application. Removing generated directory `./glimmer-stars`

Difficulties starting new glimmer app

While trying to start a new glimmer app with @lbaillie, we ran into some issues.

We first tried using the --web-component option, which returned an error:

$  ember new my-app -b @glimmer/blueprint --web-component
The option '--web-component' is not registered with the new command. Run `ember new --help` for a list of supported options.
Error creating new application. Removing generated directory `./my-app`
Unknown blueprint: @glimmer/blueprint

And then we tried it again, without the --web-component flag, but still no luck:

$  ember new my-app -b @glimmer/blueprint
Error creating new application. Removing generated directory `./my-app`
Unknown blueprint: @glimmer/blueprint

The only way that we did get it to install as expected was when we used the github repo explicitly, like so:

$ ember new my-app -b https://github.com/glimmerjs/glimmer-blueprint.git

...But this command didn't work with the --web-component flag. Our error looked like this:

Command failed: yarn add --dev @glimmer/web-component
warning ember-cli > broccoli-babel-transpiler > babel-core > [email protected]: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
yarn add v0.16.1
[1/4] Resolving packages...

We were initially using the install guide, but found that we had to uninstall and reinstall ember-cli multiple times, using bothnpm and yarn. We're guessing that perhaps something wasn't linked correctly? In any case, thought you might want to know (and maybe you can see what we were doing wrong?!) Thanks!

Strange errors after running `ember serve`

Below is the actual error @vaidehijoshi and I saw after running ember serve on a brand new Glimmer project. It otherwise builds fine, but thought you might want to know:

ember s
/src/index.ts(21,26): Argument of type 'App' is not assignable to parameter of type 'Application'.
  Types of property 'env' are incompatible.
    Type 'Environment' is not assignable to type 'Environment'. Two different types with this name exist, but they are unrelated.
      Types have separate declarations of a private property 'helpers'.
Livereload server on http://localhost:49153
Serving on http://localhost:4200/

Build successful - 3955ms.

Happy to provide any other information that might be helpful!

ember-cli-deploy doesn't work with latest glimmer-application

I recently tried to upgrade Glimmeroids to glimmer-application 0.5.1. The app works fine, but when I try to deploy it with ember-cli-deploy it hangs at Deploying [🚀 ] 100% [plugin: git -> upload] and never finishes.
Here is the branch where the problem occurs: https://github.com/t-sauer/Glimmeroids/tree/glimmer-upgrade
This is the commit which triggers the problem: t-sauer/Glimmeroids@14d12ad

Accessing ENV

How would one go about accessing ENV?

Actions without arguments break

If there's no argument, or only string literal arguments, action function is undefined.

Nested components don't appear to work as documented

Following the documentation here, creating a nested component does not allow the component to render. Even when called from within the appropriate parent component's template, an error "Could not find a template for " is thrown.

Expected Behavior

The child component should render when referenced in the appropriate parent component

Actual Behavior

Error "Could not find a template for " is thrown.

Steps to Reproduce the issue

Create a component
ember g glimmer-component parent-component

Create a child component
ember g glimmer-component parent-component/child-component

Add to parent-component/template.hbs:
<child-component/>

Here's a minimal repo that demonstrates this behavior.
https://bitbucket.org/justinross/nestedcompglimmer

Running ember-cli 2.14.0-beta.2

Attempts to Solve the issue

Checked my file/folder/template/component naming several times. Have not yet tried a different version of ember-cli

`if` helper inline form not working

{{if foo bar baz}} and (if foo bar baz) produce the error

Uncaught Error: Compile Error: if is not a helper

Iterator API change

https://github.com/glimmerjs/glimmer-application/blob/master/src/application.ts#L113 should be result.value

Advanced helpers

I'm not sure if this makes sense in glimmerland, but it would be nice to have a way to have helpers which can update their own values.

Usecases:
Timers, Observables, Tasks etc. which emit values asynchronously and need to be destroyed after removal.
Manual subscription, timerIds handling can get tedious after a while.

This can obviously be implemented in components, but for attributes/properties this does not seem to be possible.

I'd imagine something like:

export default class SubscribeHelper {
  private sub: Subscription;

  @tracked value: any;

  init(observable: Observable<any>) {
    this.sub = observable.subscribe(v => this.value = v)
  }

  destroy() {
    this.sub.unsubscribe()
  }
}

Usage in template:

<div class={{subscribe currentClass}}>{{subscribe content}}</div>

Inspired by the angular async pipe:
https://angular.io/docs/ts/latest/api/common/index/AsyncPipe-pipe.html

Documentation for running multiple apps on the same page

I was able to eventually run multiple apps on the same page, which is key for larger companies with different teams working on different services. However, I couldn't find documentation on how to implement this, as it's a little different than changing the rootElement in an Ember app.

I'm not sure if this is a possible intended use for Glimmer Apps, but it seems like it should be to me.

Require wrapping for user land helpers.

Similar conceptually to what is done in Ember-land all userland helpers should be wrapped or decorated. This allows us to incrementally improve/change/etc the helper API and provide compatibility with existing helpers.

Possible API's:

---

Similar to Ember's:

import { buildHelper } from '@glimmer/application';

export default buildHelper(function() {

})

---

Decorator specific:

import { helper } from '@glimmer/application';

export default @helper function() {

}

---

Other?

Return value of an action argument to a component always seems to be undefined for me

Return value of an action argument to a component always seems to be undefined for me

my-glimmer-app.hbs

<div>
  <my-second-component @foo={{action foo}} />
</div>

my-glimmer-app.ts

export default class extends Component {

  foo() {
    return 'hello';
  }
}

my-second-component.ts

export default class extends Component {
  didInsertElement() {
    console.log(this.args.foo()); //undefined
  }
};

Playground link: https://tinyurl.com/yc8mg43u

Argument and property naming conflict

First of all, don't know if this is the right place.

Given:

<list-component @incoming="Kelly" />

import Component from '@glimmer/component';

export default class ListComponent extends Component {
  incoming = "Selden"
};

{{@incoming}} {{incoming}}

I get "Kelly" with no errors in the console. If I change one of them to "incoming2", I get the expected "Kelly Selden". Reading about the distinction between arguments and properties, it seems like you should be able to reuse a name and not conflict.

Document (and improve) using npm packages

The first step would be to document the current status.

A further step would be to make it more seamless out of the box.

@rwjblue @tomdale Can you chime in with some discussion on what "it just works" would mean here?

I think there's some conflict between Webpack's "make CJS just work" philosophy and rollup's "try to be more conservative and force you to be precise about what CJS integration means" philosophy. We should try to make things work as well as people across the ecosystem expect them to.

`renderComponent` options API proposal

It seems like a good thing generally to change the renderComponent API slightly to accept an options object as the third argument. However, there is a detail I have feels about. This issue can serve as a place to discuss this. I would like to propose the following signature:

renderComponent(
  component: string,
  parent: Simple.Node,
  options: Dict<any> = {}
): RenderComponentResult

The only option currently supported would be nextSibling (Simple.Node). Basically, we would replace the third argument (which is currently an optional nextSibling) with an options object (Dict<any>).

The Dict<any> type is important to my proposal as I think it could be a mistake to constrain it to a particular interface. If we open it up to accept arbitrary options—combined with #89—we give custom component manager authors a lot of power to experiment since they would now be able to access any arbitrary data they may need from the "outside".

#89 gives us access to the "root" object—produced by renderComponent—inside the ComponentManager#create method via the DynamicScope argument (the fourth argument). For example, if you did:

app.renderComponent('foo-bar', parentElement, { baz: 'qux' });

Then you could use this data in your custom component manager like:

class ComponentManager {
  // ...
  create(environment, definition, args, dynamicScope) {
    // ...
    let renderedRoot = dynamicScope.get('_renderedRoot').value();
    let baz = renderedRoot.options.baz;  // 'qux'
    // ...
  }
}

`Application` has a bunch of public methods that should be private

• initRegistry
• initContainer
• initialize
• render
• rerender

`renderComponent` doesn't accept args or attributes

Current signature:

renderComponent(
  component: string | ComponentDefinition<Component>,
  parent: Simple.Node,
  nextSibling: Option<Simple.Node> = null
): void

Proposed new signature:

interface RenderComponentOptions {
  nextSibling?: Option<Simple.Node>;
  args?: Dict<any>;
  attributes?: Dict<string>;
}

renderComponent(
  component: string | ComponentDefinition<Component>,
  parent: Simple.Node,
  options: RenderComponentOptions = {}
): void

Running `ember test` on a Glimmer App breaks if run on BashOnWindows

I know this is probably not a top priority, but in the Ubuntu Bash on Windows I keep getting:

Built project successfully. Stored in "/mnt/c/Users/acimpean/Documents/projects/glimmer-weco-demo/tmp/class-tests_dist-etgV96Ai.tmp".
not ok 1 Error
    ---
        message: >
            Launcher Chrome not found. Not installed?

This is happening because Chrome can't be accessed in that context. There's a whole discussion about this on this Microsoft github issue microsoft/WSL#648 and that might be a solution.

However, running tests on an Ember App in BashOnWindows works just fine, I imagine because it can either use phantomjs (enough 99% of the time in my experience) or start a server and connect to it with Chrome.