polymerlabs / arcs Goto Github PK

Instead of sending only the handler name back, plumb the ports to handle an event(let) object, which contains the handler name and the target node's value (property) and key value. Most input elements use value for user-entered data, and key will be private data. For now, encode keys into the rendering stream (maybe attribute arc-key or data-arc-key), although if this is a sanitization issue, we can map key data to internally-generated ids for rendering.

See also #92

Particles shouldn't be able to bind to singleton views which don't have some kind of input source.

... than just using JSON.stringify

https://glitch.com/edit/#!/arcs-hello-world?path=arc.manifest

With CDN v0.0.4 I have to explicitly copy the the User view for the recipe to fully resolve. I didn't have to do this before. What are the rules that the developer should expect? Maybe that's something we could add to the manifest documentation?

The use of sync XHR in browser-loader triggers a browser warning as sync XHR is deprecated (and bad practice in any event). Using eval in the browser environment is also bad practice, and in particular makes the particle code invisible to the DevTools (maybe fixable via sourceMaps, but IMO better to fix the root cause).

Using sync XHR to load code that is then evald is double-plus ungood (6d7e5e8#diff-3063f0d93f4e10ec263645618f5aca81R75).

The best practice methods for loading code are all asynchronous and the current code expects to be able to loadParticle synchronously which IIUC means we need plumbing changes before modifying browser-loader.js.

Additionally, I think it's likely Particles will want to be able to load dependencies (code libraries, subclasses) dynamically.

Particle may declare it its manifest that the slot that it provides should be used for a particular view.
However, it is not verify, and a Particle that doesn't have this view in its connections gets rendered
(example in arcs-hello-world project)

.. and have them harvested at the end of a speculative execution

A particle declaration like this:

particle MergeBodiesOfWater in 'MergeBodiesOfWater.js'
  ShowBodyOfWater(in [BodyOfWater] in0, in [BodyOfWater] in1, out [BodyOfWater] merged)
  affordance dom
  description `Merge 2 input bodies of water ${arg0} and ${arg1}`

Won't work - the particle names don't match in the 2 declarations (MergeBodiesOfWater != ShowBodiesOfWater), and the arguments in the description won't resolve ( (in0,in1) != (arg0,argv1) ).

If possible, we should give the user load-time errors that this particle definition won't work with as much detail as possible so they can fix it easily.

We may also want to think about removing the need to state the particle name twice as it's an opportunity to make mistakes like this.

Avoid showing multiple suggestions to the user that are very similar to each other. Possibly prune all suggestions but the highest scoring one?

Need an interactive application to test dynamics and work on rendering technology.

We want to pass information from the extension (for instance, a list of tabs) via a manifest into an Arc.

The first use case we're targeting is to get a list of open product tabs (amazon.com links, for instance) and pass those as products into gift demo arc.

View supports removals but the API is not yet exposed to the particles through the Viewlet API.

Motivation: IIUC, a slot represents a display channel for a particle.

Already in the implementation we support a slot which renders to DOM and another which renders to mock (headless) DOM. Other slots may represent rendering to other contexts (other devices, or specific content areas [e.g. suggestions]).

Another issue should tackle the dependency-injection question (how SlotManager knows which kind of Slot to provide).

e.g. ListView

.. to ensure that the output slot is resolved before the input slot (so create constraints can be dealt with correctly).

The strategy-explorer and suggestions-element modules provide Web Components that we want to use in applications and environments beyond runtime/browser/demo*.

There are a few minor bits that need tweaking to support flexible reuse (mostly, removal of require and some minor factoring).

I mentioned in a team meeting that this code was forked in arcs-cdn. I think this was misunderstood to mean the design of functionality was altered, but really the changes were only to enable reuse as above. With this issue resolved, the code in this repo can be The Source of Truth and the arcs-cdn will contain only build artifacts.

Currently the Particle class doesn't allow to send the requireSlot message again.
However SlotManager should also enforce that on its side.

If Particle releases slot before it was provided (Slot Manager still has it in pending requests), SlotManager will not remove the pending request, so it will remain pending.
(I'm not quite sure what will happen when SlotManager finally provides the slot to a particle that is not pending, but the Particle's slotPromise is not delete either on release)

Pass an option to toString, eg ‘showUnresolved/Invalid’ which adds comments to indicate which parts are not resolved.
It is disabled by default.

Currently mini-particles set themselves up s.t. if their defining function returns a generator then an extraData flag will signal to the arc::tick function that the generator should be allowed to produce more data even if the input arguments haven't changed.

However, this doesn't work for particles without inputs as they would never be invoked in order to produce a generator. Further, it doesn't work for full particles. We need to make all of this work properly.

or Strateginator? :)
This is to avoid confusion between "suggestions" that currently mean suggested plans and "suggestions" that are currently named "descriptions". After this is done, description-generator should be renamed to suggestions-generator (or suggestinator?)

Shane, Doug, please, let me know when is a good time to do the renaming to not interfere with any of your work in progress, thanks!

• DomParticle
• Particle
• View
• Entity
• Manifest
• ...

resolution can fail, potentially after some type variables have already been resolved. We should move resolution constraints out of the scope and into an object that sits between the Resolver and the Scope. If resolution is successful then this object can write the resolved variables into the Scope.

move all the message generation and handling into its own, possibly generated, file

get rid of all the complicated type stuff on the particle side. This can happen entirely on the arc side, I think, leaving particles just working with bundles of data. Probably should defer until after we work out what Entities look like.

We should have a methods that cross boundaries within our team (e.g., kernel<->CDN) documented in the source, and those docs should include a comment that any API changes should have a github issue raised up for them. We hope this'll help us to coordinate these changes between the all of the repos.

These may include:

Arc (non '_'-prefix methods - constructor, instantiate, createView, commit)
SlotComposer (constructor)
Planner (constructor)
Manifest (load, _imports, _recipes)

This also probably means a bit of refactoring. I see some straight references from https://polymerlabs.github.io/arcs-cdn/v0.03/utils.js to Manifest._imports and Manifest._recipes, and it'll be clearer if we don't have direct references to '_' prefix members.

I may also be missing some. I pulled this list from:

https://polymerlabs.github.io/arcs-cdn/v0.03/utils.js
view-source:https://polymerlabs.github.io/arcs-cdn/v0.03/playground/playground.html

See #301 for a more end-user-dev doc bug (where we target docs at particle authors). There's some overlap to be aware of.

Earlier we had the Product List "from your browsing context" and "Claire wishlist" descriptions for views.
We lost them in transition to new manifest and right now everything is just "product list".
It should be improved by either putting description directly into the view, or using tags or else..

Particles can be rendered as different kinds of affordances, e.g. as a "summary" or "link" instead of "full" (?). For example a recommender might expose a sources slot and request link|summary affordances, disallowing the entire sources to be rendered inline.

Particles can also transition from one affordance to another, which might involve changing slots. E.g. a linked source might on tapping the link want to render itself as full, but do so in root slot it requests at that time (in a large screen, maybe both would be visible at the same time, hence two slots) or just need a larger size and change its affordance to editor (TBD: Can the recommender disallow that? What happens then?).

This should probably be strict matching (i.e. no automatic mapping of labels) and thus a small, slowly growing vocabulary.

incl. determining the subset of events we want to support.

requires research on whether just a subset of what gets sent in an event is enough or whether more work is needed (e.g. is the value of interest in an input field already a parameter to the event handler, so we can just subset the parameters to sanitize?)

arcs-hello-world
If splitting the particles to separate recipes:
recipe
Greet
recipe
PersonalGreet

where
particle Greet
consume root
provide personalGreeting
particle PersonalGreet
consume personalGreeting

after Greet was instantiated, a slot should become available for Personal Greet, but it is not getting resolved by the map-remote-slots strategy.

Can we prune less interesting suggestions? Or suggestions that are primarily subsets of a higher-scored suggestion?

Example: https://glitch.com/edit/#!/arcs-chat

split outerPEC from arc and tidy up the interface between them

When re-rendering slot's DOM content, release the pre-existing inner slots that do not exist in the new DOM content.
Currently only handling providing of new, and re-rendering existing slots.

Probably by not passing SlotManger to Arcs used for speculative execution.

import 'https://schema.org/Restaurant'

Fails with the following error:

jsonldToManifest.js:30
Uncaught (in promise) TypeError: Cannot read property 'subclasses' of undefined
at Function.convert (jsonldToManifest.js:30)
at fetch.then.then.data (loader.js:58)
at

It looks like multiple inheritance is missing.

for (var clazz of Object.values(classes)) {
if (clazz['rdfs:subClassOf'] !== undefined) {
var superclass = clazz['rdfs:subClassOf']['@id'];
classes[superclass].subclasses.push(clazz);
clazz.superclass = classes[superclass];
}
}

clazz['rdfs:subClassOf'] may be an array if there are multiple sub-classes.

See: https://noelutz.users.x20web.corp.google.com/www/schema.org.png

Let's us modify what the planner uses to create suggestions.

Each has a checkbox so we can turn it on and off.

They are all manifests (static files) or arc urls (which storage shim would load), but could be grouped as:

• "particle index", point to a firebase that lists all "published" particles
• in-progress particles, point to manifests on e.g. glitch instances for particles in development
• data, manifests that contained serialized (static) arcs:
  • about the user
  • from other users shared with the user, e.g. wishlist (maybe grouped by "other user"?)
  • from locations
• context from extension
• inline text box for anything else

Probably need a way to prioritize some of those, meaning suggestions need to use at least one view from that source. Let's tackle this after the the above is set up.

E.g., https://glitch.com/edit/#!/arcs-chat. The chats view specified in the manifest isn't copied and hence isn't part of the suggestion (because the compose particle writes to it).

Shane replied:

you can't write to a manifest view because it's a static definition. There's a "copy" fate for this purpose, though - I don't know why the planner isn't suggesting that, will try to figure it out today

• Merge Scott's CDN changes into master (gulp file, ...)
• Create PolymerLabs/arcs-cdn repo and push an initial Arcs library.
• Document CDN push process