Question: Communication App <--> View

[bwh-rl]

Hi all.

I am testing the polymer-starter-kit way of creating an app. We have an running polymer app started on 0.5, rebuild with the 1.0 release, with lots of content.

What we implemented for the 1.0 was an app-behavior and an view-behavior, with the app-behavior iterating its elements and gives references to itself to all view-behavior elements.

So if e.g. the main drawer should be hidden from a view it's kinda this.app.$.myDrawerPanel.close();.

How am i supposed to implement something similar "the starter-kit" way? Just <my-view1 name="view1" app-reference="[[appReference]]"></my-view1>?

[robdodson]

Generally we recommend not coupling things together in this way. Views should dispatch events to tell their parent elements, sometimes referred to as mediators, that something has changed. The view itself doesn't know about or care that this change will cause the drawer to close. It's up to the common parent of the view and the drawer to decide that based on the event.

So my-view1 might dispatch an event, which my-app listens to and it then decides to close the drawer.

Btw, if you're just specifically interested in closing the drawer when something changes I'd recommend looking at the approach used in Shop where they bind the opened state of the drawer to the router. https://github.com/Polymer/shop/blob/49fc752942f718dbf1d6055bab45bfc95567e2c7/src/shop-app.html#L294

[bwh-rl]

Thanks for the hint with the opened state and the router! You are right, and this was an bad example and should be done via events.

But what is with toolbar <--> view communication? If there are e.g. different toolbars, they would be in separate elements just like the view and switched via routing.

There are a lot of different actions a toolbar can start, while some can be reusable like a e.g. an reload-button sending an reload event to the app giving the active view an call to it's reload function, some actions would be unique to a bar and a view.

In short - if you have an big app you will end up with an very long list of event listening functions inside the app that are just "passing through".

[robdodson]

You could try to bundle the toolbar with the view, or you could put the toolbars in a dom-if that toggles their display state based on the state of the router or some other property

[jfrazzano]

I had a similar issue and went around it, to a much better more efficient solution, that also provides a richer user experience by just letting data control the views and interactions, and who-ever the user is, or whatever he or she wants to do--that forms half of a key, the other half is made by what is actually available, the combined two pieces determine content. Its very flux, straight path "routing"--but gives the user maximum freedom.

I could attach a screen shot or toss pieces in a code-pen, when I move more fully to 2.0. I was skeptical at first, but this is really a way better ui approach imho;

[bwh-rl]

@robdodson Thank you for your input! @jfrazzano i would really like to see your approach if it is possible.

Bundle the toolbar with the view has imho to many drawbacks.

• Multiple paper-header-panel's instead on one.
• No possibility to animate small to big toolbar changes.
• No possibility to reuse toolbars (like e.g. having an default toolbar with just an hamburger that works with e.g. 50% of all views)

I think dom-if is not a great approach to switch toolbars, but i understand that this is possible and i will switch toolbars depending on the route (As i wrote in my previous post).

My only concern is ending up with one big, hard to read app-element with a lots of event listening functions. But i understand your reasons for recommending this approach.

Maybe a more valid approach to enhance maintainability would be splitting the complete my-app code into behaviors? Like e.g. myAppResizebehavior, myAppRoutingBehavior, myAppCrossElementCommunication.

[jfrazzano]

i have a dynamic header, resizes text to width and height, fonts etc, it is a step function now in the general version, in the column specific--meaning i didnt throw a general template on the page and just spray data at the multiple panels, it had more interesting animation, ratio sizing and was ready to get browser device data, but I waited for full implementation as i did not know anything about how spec change would go. I knew I relied heavily on statefulness... a little hoisting of data-measurements. I--stupidly--completely disassembled Keanu's handler. It stopped me from measuring and maintaining my 7-10 panels prior to render and explicitly skipped or gave a jump if i tried to readjust prior. One of our implimentation requirements was if system fell, to return to identical state...

leave your desk a mess... come back tomorrow... desk a mess.

That is not so possible now in native custom element spec, or in what we so far have of Polymer 2.0 now. That doesnt mean its not possible... it just means-- as far as I can tell, that shadow dom specs, and the necessary reliability incumbent in a world wide, all tech levels standard requires a more predictable api, and a less monkeyed with, erratic, everyone monkey patches everything ,platform. That said, template literals, spread operators, generators* (sort of now), l, the dynamic reg ex, and then using symbol assembly of unmatched pairs allows basically anyone to assemble their own dome, on demand, as fast as possible, and with relatively solid security.

I say this as someone who came to coding last May in a light--I used wordpress and couldnt find the dashboard(it is the dashboard) kind of way. But by January of 2016, a result of developer bills soaring to $40,000 a month, not a single page ever built and functional, and our little company sorta left saying wtf... I said, "I demand kids go learn scary foreign things every day. Time to man up." I couldnt even read code books with any level of fluency until this may. Then all at once I could read.

I left Polymer developing of our system on the 14th of september and started doing what all the polymer dudes told us to do, I used the platform.

Here are dynamic column, generated by a string template, a dynamic pass works too if you wanna break rules, I only figured out the templating yesterday. Its three protos... bad html for first two protos... second one has a whole template string hidden in a data property and hides other needed strings in 1px sections. Third section is one ol....

am working on linking the line numbers to the passages... and stripping the css as much as possible.

Almost all css is just a straight rip of polymer FLEX BOX classes... Only css issues really annoying are left theft of padding and scroll height window height differences on monitors devices...

here is pen, I will send you whatever you like... literally build about 8000 elements... a lot of crap... some gems

https://codepen.io/jfrazz/pen/d80f01cd57fb8d358bfcc607151d127c

On Tue, Sep 20, 2016 at 10:18 AM, bwh-rl notifications@github.com wrote:

@robdodson https://github.com/robdodson Thanks for your input! @jfrazzano https://github.com/jfrazzano i would really like to see your approach if it is possible.

Bundle the toolbar with the view has imho to many drawbacks.

• Multiple paper-header-panel's instead on one.
• No possibility to animate small to big toolbar changes.
• No possibility to reuse toolbars (like e.g. having an default toolbar with just an hamburger that works with e.g. 50% of all views)

I think dom-if is not a great approach to switch toolbars, but i understand that this is possible and i will switch toolbars depending on the route (As i wrote in my previous post).

My only concern is ending up with one big, hard to read app-element with a lots of event listening functions. But i understand your reasons for recommending this approach.

Maybe a more valid approach to enhance maintainability would be splitting the complete my-app code into behaviors? Like e.g. myAppResizebehavior, myAppRoutingBehavior, myAppCrossElementCommunication.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PolymerElements/polymer-starter-kit/issues/918#issuecomment-248314740, or mute the thread https://github.com/notifications/unsubscribe-auth/AHxnvp4NUB8A9xxpnAT2qkzJEYaRoxMzks5qr-sigaJpZM4J84NN .

---

Jason C. Frazzano Esq. Founder and Master Coach, Focused Coaching Stanford University, B.A. M.A., with honors and distinction Columbia Law School, J.D., Stone Scholar www.focusedcoaching.com jason@focusedcoaching.com jfrazzano@gmail.com office: 732-671-1834

[jfrazzano]

oh, hit the giant button on the code pen to see the dynamic columns... The right ways to do it are (a) collect client device data in sleep mode to find sweet spots in iterative math approach, need to access resolution-- which is a bbbb... in some systems. (b) use a dom string query and bind/listen to sets of nodes and have them fire clicks to create a triangulation-radar system. Was way freakin easier with dom list of anchors that reported position since dom 0/1 but that is supposed to go, so you do it the other way. not terrible. Just low priority for me now

On Wed, Sep 28, 2016 at 1:03 AM, Jason Frazzano jfrazzano@gmail.com wrote:

here is the header behavior-- there are th screenshots from 9.5, before a 9.10-9.12 2.0 shift attempt/ Each of three panels holds at least three panels. the panels slid up and down, and across, header resized in version two with width and height... this one i believe only on width. There were some issues with binding, where I had to leave the binding system to make it "fully iterable". Same issue occurred in relation to the resizer tag/resizer column/ splitter sort of element... you can have that too. I opened (made public) the git hub repositories that my project used. Best stuff included the iss input... no longer to spec. Transformed from a input, to a input searchable dropdown, to a menu, to a survey, to radio buttons. Drop down maintained focus color on top item in drop down scroll even holding 1200 items in dom repeat-- no iron ajax. Loaded as many as 64 at of the elements at once to fill pages of forms.

the resizer is solid. The grids (there are like ten or twelve) resize to text, have a right click context menu that will add remove columns, change column highlighting, text, etc. There are versions in grid, dashboard and to transport for native, polymer 1.1-1.6...

other cool items are the clock... they now crack polymer 2.0.. their hoisting to global scope to keep them on page even when page changed in old router caused a polymer loop which shuts down machine... if you have an old version running, take design and animation and rewrite off thread greedy generator*@@generator api that steps through events and pushes in a "greedy way" so it pre-does anything it can and then retuirns to last place. You have to monitor stack too if you are in background... You have a few users (assuming you stupidly) add it to a router or sys manager... and the stop watch to the thousandth of a second, cloning it self on multiple pages pretty much wrecks your house... There are way better way s to make it.. That was the first api I ever made.

Calendar is cool, suffers from same issue, but has resizing shifting header.

look and ask. I would know nothing and could have made nothing if I werent tied to this thread, and without the support of this community... That said... I still know nothing

;-)

---

Jason C. Frazzano Esq. Founder and Master Coach, Focused Coaching Stanford University, B.A. M.A., with honors and distinction Columbia Law School, J.D., Stone Scholar www.focusedcoaching.com jason@focusedcoaching.com jfrazzano@gmail.com office: 732-671-1834

---

Jason C. Frazzano Esq. Founder and Master Coach, Focused Coaching Stanford University, B.A. M.A., with honors and distinction Columbia Law School, J.D., Stone Scholar www.focusedcoaching.com jason@focusedcoaching.com jfrazzano@gmail.com office: 732-671-1834

---

Jason C. Frazzano Esq. Founder and Master Coach, Focused Coaching Stanford University, B.A. M.A., with honors and distinction Columbia Law School, J.D., Stone Scholar www.focusedcoaching.com jason@focusedcoaching.com jfrazzano@gmail.com office: 732-671-1834