polymerlabs / arcs Goto Github PK
View Code? Open in Web Editor NEWArcs
License: BSD 3-Clause "New" or "Revised" License
Arcs
License: BSD 3-Clause "New" or "Revised" License
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.
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 eval
d 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.
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.
Pass an option to toString, eg ‘showUnresolved/Invalid’ which adds comments to indicate which parts are not resolved.
It is disabled by default.
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..
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.
... than just using JSON.stringify
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.
View supports removals but the API is not yet exposed to the particles through the Viewlet API.
Particles shouldn't be able to bind to singleton views which don't have some kind of input source.
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.
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)
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?)
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!
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.
e.g. ListView
Need an interactive application to test dynamics and work on rendering technology.
move all the message generation and handling into its own, possibly generated, file
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
.. to ensure that the output slot is resolved before the input slot (so create constraints can be dealt with correctly).
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
Currently the Particle class doesn't allow to send the requireSlot message again.
However SlotManager should also enforce that on its side.
split outerPEC from arc and tidy up the interface between them
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
Probably by not passing SlotManger to Arcs used for speculative execution.
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.
Avoid showing multiple suggestions to the user that are very similar to each other. Possibly prune all suggestions but the highest scoring one?
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
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)
.. and have them harvested at the end of a speculative execution
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?
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.
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).
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.
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:
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.