Polymer Team - I'm really frustrated!

@tjsavage and the Polymer team, I am really frustrated with the Polymer Project / team!!!
I believe there are very few frameworks out there that are so committed to taking full advantage of and working so close to the metal of the amazing next generation web platform and specifically the Web Component technology set! Polymer should be (is?) that project!  The tech benefits for WebApp development using Polymer is a no-brainer on many levels IMHO...
I keep seeing tweets and articles like this which continuously show the performance benefits of sticking with the platform and therefore Polymer!
https://twitter.com/paulcuth/status/837632180352401408
https://twitter.com/marcushellberg/status/837451438418616321
https://aerotwist.com/blog/when-everything-is-important-nothing-is/
(there are many more)
So why is Polymer not totally buzzing right up there with these other frameworks - React, Vue, etc.?  Why is the community not jumping on this?
From the outside looking in I can only attribute this to two possibilities:

A lack of energy from the Polymer project management team who I feel do not spend enough time pushing the benefits of Polymer through the various media channels...  It just feels like there is no energy there...
Internally Polymer is possibly a conflicting project with other projects such as Angular and is therefore not being pushed!?

On the first point:

why does this issue have comments like "it would be nice if there is a little more communication", "Again, a update of the current state would be nice?" and "No News? Would realy be interesting to know where we are? When can we estimate first release?". Feedback on how things are to the community is slow and usually comes from issues like the one above.
Polymer has been slow to adopt ES6/7 which other frameworks like React, Vue are not scared to assume by default - I understand the no-build concept but these days nearly every decent framework requires a build step!  Just package built & unbuilt code in the same projects and default to the built one.
Recently, not taking the perfect opportunity on the v1.0 release of the Web Component spec to solidly make 'breaking changes' to Polymer 2.x and therefore transport it into a project that competes with frameworks like React/Vue in terms of popularity - look at the Github Stars for these projects (React 61K, Vue.js 45K, Polymer 17K)!
In v2.x not providing an imperative API that supports runtime DOM composition that makes binding to existing parent element just work - is this a design flaw in Polymer?

On the second point, it's anyone's guess - this is unlikely though, I would think!
Another point - look at the job market and compare the call for React jobs vs Polymer jobs!
The Polymer Project is such an opportunity to be the framework that drives Web Component technologies into being better supported by all modern browsers!  Why is this not happening!?
If it doesn't take this opportunity then we may see another framework take up it's position of being the Web Component framework of choice!!!
I truly do not mean to offend here, if anything, I would like to see Polymer at least reach the level of recognition it deserves - right up there with React, Vue, etc!!!
How can we get it there!?

IMO building Polymer apps is kinda like a back to Backbone times. I mean, Polymer is great to build components, but offers very few project-level architecture solutions.
This can be partially fulfilled by projects like UniFlow for Polymer, and Polymer Redux, but for a long time we didn't have any guides on this.
So, when using Polymer, project-specific part of the code is much more bigger than framework-specific. This means that switching to a different project might be pretty hard, as you will need to learn new concepts and solutions adopted by that project's team.
Another thing is tools. A month ago we received a new polymer-bundler, which is a lot more faster than vulcanize used to be. But these existing tools are less powerful than Webpack and sometimes require few spec-related tricks to work (e. g. not so easy to implement HMR due to lack of ability to unregister element, etc).

Hey guyz, take it easy...
Polymer 2.0 is on the way, I can't even imagine how much effort these guys are putting on it
I am sure we'll have tons of news when we get 2.0.0-stable

Hey @clintwood!
I hear your frustration, and appreciate your enthusiasm. We think there should be much more buzz too!
Polymer's growth has been tightly and necessarily constrained by broad adoption of the Web Components specs. I'm sure I'm preaching to the choir here about the promise of Web Components: platform-level, encapsulated component model, to make sharing components/possible easier across frameworks, to not have to re-invent a component model for every new framework, and ultimately to allow devs to write higher-level code while shipping less JS down to the client.
The Polymer project was designed to prove out Web Components, help shape the low-level API's themselves, and then ultimately to make it easier to build Web Components.
The history of the project has very tightly progressed along these lines:

Polymer 0.1-0.5 releases were all about proving out early Web Components, as well as looking to tie in additional experimental specs (remember Object.observe!). With this, we helped bridge the gap between spec authors and developers to land on what might work and what might not.
Polymer 1.0 was about proving Web Components could be used in production. This meant optimizing for performance - this is where Shady DOM came in so that we wouldn't have to lug around the full Shadow DOM polyfill on Safari.

Even with Polymer 1.0 though, we haven't come close to realizing the full potential of Web Components. True encapsulation, true re-usability, truly minimal JS is not possible without broad browser support for native Web Component API's. Polyfills are typically fine on desktop browser with big beefy CPU's and Wifi/Cable connections, but they do matter on mobile browsers.
Unfortunately, even though I think we've shown that despite polyfills you can still ship really fast, powerful experiences on mobile using Web Components, and even though I believe relying on polyfills should be considered an advantage, not a weakness, given that they disappear over time, the current state of Web Components is an incredibly easy thing to nitpick.
So while we're in this uncanny-valley, rather than target broad, Hacker News-type reach, we've been targeting large organizations and products inside and outside Google - those who have an immediate and crushing need for Web Components today - to make sure the project and toolset works for these use-cases.
As you note, we've recently hit a major milestone for Web Components - the Web Components v1 specs. Unfortunately, they haven't quite all shipped yet - Safari is yet to ship Custom Elements v1, though it is completed in Tech Preview. But we're extremely close.
So we've designed Polymer 2.0 to fully embrace these v1 specs. And we've been working hard to get 2.0 production-ready before v1 completely lands.
Polymer 2.0 is designed to actually realize the full promise of Web Components. One quick way to see this - here is a table showing the combined size of Polymer + the polyfills required to use 2.0's class-based element syntax:

Native Browser Support

Combined size of Polymer & Polyfills (in kb, gzip)

Browser
HTMLImports
Custom Elements
ShadowDOM
Other Platform
1.x
2.x (legacy API)
2.x

Chrome
✔
✔
✔
✔
53
23
10

Safari w/ CEv1

✔
✔
✔
53
26
13

Safari 10

✔
✔
53
30
17

Firefox

✔
53
45
32

Microsoft Edge/IE

53
49
36

Polyfill size
3.5
3.7
14.8
3.5

The more specs supported natively, the less code required. Down to ~10kb on Chrome.
I wish we had a magic switch we could pull that would make Web Components wildly popular. By hitching our cart to the Web Platform horse, we're at the whim and the pace of the overall spec adoption - which is a long arc. Thanks to Google's backing we've been able to take this long view - to target the long-term paradigm shift rather than seeking short-term popularity.
I have not done as good a job as I'd like keeping the community updated on our progress - this is something we're actively working on changing our culture around.
We've also needed to conserve our credibility. As we all know, web developers can be an opinionated bunch :). We set out our long-term thesis and set the goalposts when Web Components v1 first solidified. Rather than continually pound this drum, we've put our heads down the last few (many) months to execute on this. The result will be Polymer 2.0, which will be released imminently.
We hope 2.0 will be a major transformation in Polymer's broad appeal. But we need this amazing community's help:

We need help with feedback on the 2.0 release candidate, to make sure we end up shipping the right thing to stable. The community is absolutely critical here. We'll have more information coming on this release candidate very shortly.
We need help building up a corpus of content on the web about Polymer. Answering StackOverflow questions, posting "How to get started" blog posts, etc.
We need help growing the set of high-quality components available in the ecosystem - publishing to webcomponents.org. The set of components on webcomponents.org has been growing in leaps and bounds - let's keep it growing!

I hope this at least speaks to your concern, @clintwood. As a team we're pouring our hearts and souls into building the right next product, with 2.0. We need all the help and community energy we can get to make sure it's great. From there, I think we'll have a solid foundation to reach the popularity you're hoping for.

We're doing an issue scrub on Polymer/polymer currently - I'll move this thread to github.com/polymer/project where we try to keep these convo's open

This issue was moved to Polymer/project#36

Hello, based on the human being characteristics, many developers are scared of changes, on the other hand Web components look basically is a substantial change in Web development industry( in wrting code & its approach), so of course shifting in Polymer brings new problem and of course new solutions, but another factor that makes Polymer powerful is trusting more people on it for their real web scenarios( your software ).

Again... 2 months... no new infos... Whats happening to designer? What are the plans of the team now, since polymer 2 is released? What are the plans about html includes or es6 modules?

I agree that there's more transparency needed. What's so hard about creating pull requests and showing progress there? I like how the html modules are approached on the github repo. Recently on the npm migration topic, one of the biggest ones, someone asked for a PR - no reply.
The answer is "we are working on it". Don't get me wrong, I do believe you are working on it, and the Polymer team is far more competent to get it done than the majority of developers relying on Polymer, but a little transparency what you're actually doing would be nice to have.
Transparency is better than just bullshitting us - we've also heard that html imports are coming for the last idk ... 3 years? It would be nicer if it would be kept real and expectations are realistic, not wishful thinking.
Also, no roadmap update after 2.0, which probably was your most significant webcomponents release so far is also meh :/

I believe Polymer project cannot be judged normally with others, It's not correct.
Web component on its own, is a new standard, so Polymer doesn't mean just as a library, that's why it's named polymer project.
On the other hand, it's developed enough, of course every software out there need constant development...

There already is a working web component framework, it existed since 2006 as such, and is still being developed. It does not have special system requirements, so it works cross-browser and even on the server side out of the box. It supports lazy loading of web components (recursively). Also it easily digests autonomous web components /w a polyfill.  Look at this small app code example, its is self-explaining: twobirds todoMVC app footer
The API is documented within the package twobirds-core API, but additional support is meager so far. This will change in the nearer future, though.

I don't know about it but when I opened its website it was like since 2006 hasn't been changed... :-)

Thats why I am (so far locally) working on a website now ... but trust me the system covers all needs, and I recently used it for very complicated multi-tier programming in a multi-datacenter microservice environment.
Since it has been a one-man show for so long I was limiting myself to jsDoc auto-documentation, but all feedback I get is about a website for examples, tutorials and better docs obviously - I had to start doing this now. Feel free to contact me on skype frank.thuerigen

Good job, "but all feedback I get is about a website" I do understand that the feedbacks firstly should be about the code itself therefore will be valuable, but there is a reality which is on the (introducing)website at least there should be a simple definition along with basic examples, thus I feel more eager to discover the philosophy and ... behind it.


How can I tell if and Either is Left or Right?

Can't find any method in the docs.

Curious if you can give an example of needing to do this.
There is nothing in crocks that does this for a few reasons.
But you can make a set of functions if you need to do this like so:
const { constant, either } = require('crocks')

// isRight :: Either a b -> Boolean
const isRight =
  either(constant(false), constant(true))

// isLeft :: Either a b -> Boolean
const isLeft =
  either(constant(true), constant(false))

Though if you could post an example of how you would use these functions, I may be able to show you how to not need them, and just rely on the Disjunction that is encoded in the Either type.

Thanks @evilsoft
I am using Either to validate, the user's input. As part of the codebase if built with Folktale's data.task, I want to to transform my Eithers into a Task, so if there is any Left in the object, it goes to Task.rejected with the contents of the Lefts folded. Else it goes to Task.of also folded.
const validateCreateUser = R.pipe(
  R.applySpec({
    fname: body => isNilOrEmpty(body.fname)
      ? Left('El nombre es requerido')
      : Right(body.fname),

    lname: body => isNilOrEmpty(body.lname)
      ? Left('El apellido es requerido')
      : Right(body.lname),

    email: body =>
      isNilOrEmpty(body.email)  ? Left('El email es requerido') :
      !isValidEmail(body.email) ? Left('El email es no es un correo válido')
                                : Right(body.email),

    password: body =>
      isNilOrEmpty(body.password) ? Left('El password es requerido') :
      body.password.length < 6     ? Left('El password debe ser de al menos 6 caracteres')
                                   : Right(body.password),

    password_confirmation: body => body.password !== body.password_confirmation
      ? Left('El password y su confirmación no coinciden') :
        Right(body.password_confirmation),
  }),
  fromValidatedEitherToTask
)

At the moment I switched to data.either, so fromValidatedEitherToTask. But I guess there must be a better way
const fromValidatedEitherToTask = objOfEithers => R.pipe(
  R.partition(either => either.isLeft),
  ([left, right]) => R.isEmpty(left)
    ? Task.of(R.map(r => r.fold(R.identity, R.identity), right))
    : Task.rejected(R.map(l => l.fold(R.identity, R.identity), left)),
)(objOfEithers)

Ah. I see, yep you are forced into that with partition.
You could move back to crocks Either and do the `` with T and F from ramda.
then while it is the same flow, you could do something like:
const { bimap, either } = require('crocks)

const isLeft =
  either(T, F)

const rejectFirst = R.ifElse(
  R.compose(R.isEmpty, R.head),
  R.compose(Task.of, R.nth(1)),
  R.compose(Task.rejected, R.head)
)

const extract =
  R.map(either(R.identity, R.identity))

const fromValidatedEitherToTask = R.pipe(
  R.partition(isLeft),
  rejectFirst,
  bimap(extract, extract)
)

You will be in the same boat as before, so this really adds nothing.

Thanks for taking the time to elaborate on that example. It's very cool!

Hi,
I was following the topic and seems that you could go about using tagged predicates as @evilsoft showed in one of the earlier videos (https://www.youtube.com/watch?v=I7yvTw2Yoo0).
The solution is very elegant for taking first error message that comes in the list of validations and it is given back as a Maybe which you can chain further to a Task.


odd viability phenotype

This might need to go on website tracker, not sure.
When I filter "ark1" on "viability phenotypes" I see
normal growth on camptothecin?
(but this filter  excludes  chemical sensitivities, so I did not expect to see this)

It's because all of the "normal growth on x" terms are is_a FYPO:0001357 ! normal vegetative cell population growth. It's a little odd because it implies that the parent means "normal growth under some set of conditions" rather than "normal growth under any and all conditions". But if we didn't do it that way, I'm not sure how we could give the "normal on x" terms logical definitions.
Oh, and FYPO:0001357 is_a FYPO:0002060 ! viable vegetative cell population, because if a population is growing at all it's got to be viable.
I haven't put sensitivity terms under viable or inviable, because the degree of sensitivity can vary such that a population may be viable or inviable on a given x, but I can think about whether it would work to move to viable. Not sure without a think.

Its probably not a problem, I just thought it seemed strange at frist glance  but it makes sense...

OK. In the meantime I thought up another possible approach. I'll close this until/unless we get user confusion or complaints, but will record my crazy idea in case we need it:
I could kludge xps for most of the normal on x terms as intersection_of "normal growth on chemical substance" (FYPO:new), and then only the new grouping term and the IR and UV terms would wind up directly under FYPO:0000139 ! cell population growth phenotype or FYPO:0001358 ! vegetative cell population growth phenotype.
If that sounds like gibberish, don't worry; I'll know what it means and can explain later if we wind up doing it ;)


Ability to define Phab conduit credentials per job?

Hi,
if I define more than 1 Phab conduit credentials in Jenkins, it seems that I cannot select which one a single job will use. If "Default Phabricator Credentials" is none, then build jobs fail and if I choose one from the list, then jobs that need to talk to other Phab instances fail.
Do I miss anything? Nice job btw.
Regards,
Kostis

Nope, this is probably just a bug/limitation in the implementation. In every set up I've seen, there's been a 1:1 mapping between Jenkins and Phab instances, so I went "full YAGNI" and didn't write anything to handle multi-phab-per-jenkins setups.
In your case, are you talking to different phabricator installs, or is it that you want to use different users on the same install?

Yes, my initial intention was to configure credentials for repos across two phab instances and have jobs that will be based on both of them. I don't know if you want to consider it as a feature request for the future but right now I realize I need to go 1:1 between Jenkins and Phab instances. I will close this if you don't mind.

I think it's a valid feature request, I'm just not going to have time to
implement it any time soon.
I think we should leave the issue open, and maybe you or someone else will
have time to implement it.
On Wed, Jul 20, 2016 at 1:16 AM kosfar<EMAIL_ADDRESS>wrote:

Yes, my initial intention was to configure credentials for repos across
two phab instances and have jobs that will be based on both of them. I
don't know if you want to consider it as a feature request for the future
but right now I realize I need to go 1:1 between Jenkins and Phab
instances. I will close this if you don't mind.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/uber/phabricator-jenkins-plugin/issues/168#issuecomment-233879410,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAF7P38x97Ap4iZxMjOLp2q-7ivSkpaqks5qXdl1gaJpZM4JP4OI
.


4 indents instead of two in nested arrays

Hi & thanks for the hard work!
Working with nested arrays to render HTML, it feels like there's 2 spaces added. Here's an example:
render :: Int -> ComponentHTML action () m
render _ =
  HTML.div [ Properties.class_ $ HTML.ClassName "body" ]
    [ HTML.nav
        [ Properties.class_ $ HTML.ClassName "navbar" ]
        [ HTML.div []
            [ HTML.div []
                [ HTML.text "Dashboard" ]
            ]
        ]
    , HTML.nav
        [ Properties.class_ $ HTML.ClassName "sidebar" ]
        [ HTML.text "Nav right" ]
    , HTML.main
        [ Properties.class_ $ HTML.ClassName "main" ]
        [ HTML.text "main" ]
    ]

I would expect to have something like this:
render :: Int -> ComponentHTML action () m
render _ =
  HTML.div [ Properties.class_ $ HTML.ClassName "body" ]
    [ HTML.nav
      [ Properties.class_ $ HTML.ClassName "navbar" ]
      [ HTML.div []
        [ HTML.div []
          [ HTML.text "Dashboard" ]
        ]
      ]
    , HTML.nav
      [ Properties.class_ $ HTML.ClassName "sidebar" ]
      [ HTML.text "Nav right" ]
    , HTML.main
      [ Properties.class_ $ HTML.ClassName "main" ]
      [ HTML.text "main" ]
    ]

Otherwise, it appears a little bit ugly on a text editor with indent guides, where the editor clearly display 4 spaces:

Is it on purpose? Is it because of how the code is parsed? Do you think it could stick with 2 spaces in such case?

It's on purpose, it's a subjective aesthetic choice which apparently you are not in favour of :smile:.
I like it personally because I find it makes it much easier to see the structure of things through the alignment, it's less distinct tin the singly-indented case to my eyes.

This is intentional, consider:
example = do
  let
    foo =
      a b c
    bar =
      a b c
  foo + bar

example =
  { foo:
      a b c
  , bar:
      a b c
  }

infix 0 Tuple as :=

example = Map.fromFoldable
  [ "foo" :=
      a b c
  , "bar" :=
      a b c
  ]

The alternative would be:
-- Indentation is required in this example
example = do
  let
    foo =
      a b c
    bar =
      a b c
  foo + bar

example =
  { foo:
    a b c
  , bar:
    a b c
  }

infix 0 Tuple as :=

example = Map.fromFoldable
  [ "foo" :=
    a b c
  , "bar" :=
    a b c
  ]

It is an aesthetic choice here which leading-comma style makes a bit awkward. My reasoning is that , is very low visual weight and nearly indistinguishable from whitespace when scanning code. With strict 2-space indentation, indented code is visually aligned to the same column as the leading code. I've chosen to indent past the leading code to restore the visual hierarchy.
It's true that it's not perfect 2-space indentation, and there are some code examples where it can appear to be indented more than that.

Thanks for the answer! I understand the rationale 🙂
Let's agree to disagree on that point, I find your example easy to read enough, but I get why you implemented it like that.
Purs-tidy is (unfortunately) not for me then, thanks again for your quick answer!


ForgeJS 0.9.4 release

Changelog and small patches for release

 All committers have signed the CLA.


Change/clarify explicit stringer definition

The explicit definition of the wingStringerType leaves all parameters optional.
If the  element is not specified, it defaults to 0. This is quite meaningless, as this allows to define a  element which defines no stringers. After discussion with @rmaierl we think the default value should be changed to 1.
Furthermore, the angleReference parameter specifies: "If the reference of the stringer angle shall be different from the default implementation then this parameter may be set". This leads to confusion about what the "default implementation" is. We would like to have one of the specified values here as default (e.g. leadingEdge, maybe also globalY).
What are your thoughts?

As described in #511 the options cannot be made as suggested because that leads to a name clash in XSD. We would have to add an additional node layer to realize it. Please continue this topic in #511.
The default value is described in the "angle" description and illustrated in the remarks section.

the reference axis for the stringer angle is defined by the two leading edge  points of the 'from'- and the 'to'-element of the componentSegment definition.

And the z direction of the reference axes is depicted perpendicular to that reference axis and the wings x-axis.

Closed with #557


tests: fix exception policy midstream tests - v1

From what I understand, the README file description for the 'bypass' (midstream-05) test was wrong, and the test for the 'pass-flow' (midstream-04) wasn't actually acting as expected due to not having midstream set to true...

Replaced by: https://github.com/OISF/suricata-verify/pull/1053


Payumoney

Hey, can you add this payment gateway also @amacneil. Link to their website is here => https://www.payumoney.com/dev-guide/webcheckout/redirect.html

The correct way to do this is to submit a PR on this repository -- adjust the README.md file to include the gateway details, maintainer, etc.


Migrated notifications to Firebase

Fixes Issue: https://github.com/snapshot-labs/snapshot-webhook/issues/23
Changes in this PR:

[x] Removed Pusher Beams integration
[x] Setup Firebase SDK for receiving push notifications
[x] Setup service worker to receive background notifications
[x] Moved notification bell icon from individual space to Notification tray on top right corner

How to test and review this PR?

Configure Firebase credentials (Ref: https://firebase.google.com/docs/cloud-messaging/js/client#configure_web_credentials_with)
Enable browser notification from the Notification tray on top right corner
On proposal created/deleted event, a push notification is received for the spaces user is following

TODO:

[ ] Better way to import Firebase config within service worker and src/helpers/firebase.ts (Ref: https://github.com/vitejs/vite/discussions/9023)

Can you fix the conflicts here?

@eswarasai I've converted this PR to a draft as I see some things missing and the preview deployment doesn't work.

@eswarasai have you tried this https://stackoverflow.com/questions/73355783/proper-way-to-setup-firebase-messaging-service-worker-with-vite

@eswarasai can you resolve conflicts

Keep this


Change implementation logic for getting DB schema

Create LRU cache to store DB schema
Add logic for getting DB schema from either database or cache
Remove cache
Add unit test for above functions

@Lucy911 could you rebase from the master? @formuzi did a fix for the CI and merged into master already.

@formuzi @fzxu Looks like the CI job still error out with old var "undefined" which has been changed to new var such as "CacheSize" to "cacheSize" in server.go

@Lucy911 did you rebase from master?

@Lucy911 the code still using CacheSize instead of cacheSize

@formuzi @fzxu I did rebase. Where should I see the changes from Sen's fix?


143- Migrate Next.js and Storybook and fix compile errors

Issue Number
Closing #143
The files changed in this PR:
System files

.gitignore
package.json
Dockerfile
sentry.edge.config.js  (a new file added 18b8526)
yarnrc.yml (a new file added)

( .yarn directory was auto-generated)
Storybook

./storybook

main.js
preview.js
./stories/components/* (minor updates in each story's titles)

Component

Anchor.js (in shared, minor change 0405716)
The mock data for the experiment and its code block were removed due to warning "fine_name" exceeds the max of 500KB (53308bc)
A minor change in PageTitle due to the title format data type warning (c3d8a94)

Purpose/Implementation Notes
Resolved the compile errors in order to run theyarn start-local or yarn start-storybook scripts to start the storybook, and now all the scripts run without generating errors and start the services on specified ports  🎉
Please preview the storybook deployment here (*for the client preview here).
Instruction
To run the scripts in local, please follow these steps.
In the terminal:

Update Node.js version to 18.17 (matches our docker image) or higher or switch version using nvm (👈 I highly recommend, if you haven't yet)
Set yarn version to v3 globally by running yarn set version stable (switch yarn versions)

If you've already pulled this PR locally, please follow these steps. otherwise skip.
In the project root:

Delete the following folders: .next, node_modules, yarn.lock
Run yarn cache clean to clear the yarn cache

Finally please follow these steps.

Run yarn install to install the packages
Run the available scripts.

Types of changes

Breaking change (fix or feature that would cause existing functionality to not work as expected)

Functional tests
List out the functional tests you've completed to verify your changes work locally.
Checklist

[x] Lint and unit tests pass locally with my changes
[x] I have added necessary documentation (if appropriate)

@davidsmejia  I reverted back the change I made while testing the repository locally. Please pull this commit 217825e before the review, thank you!