React Spike: Rewrite the MDN page header

User story
As an MDN developer, I want to rewrite the MDN page header using React, so I can gain experience using React for a non-trivial page component, and so that I can reduce our the dependencies on jquery.
(Also, as an MDN user, I don't want the menus at the top of ever MDN page to appear every time I move my mouse pointer near them.)
See https://bugzilla.mozilla.org/show_bug.cgi?id=1525719
This issue is intended to be tacked after issue #965 and issue #966.
The goals of this work are:

to do a non-trivial chunk of React coding, to help ensure that the toolchain we're using is suitable

to prototype a positive UX improvement for the site (fixing the menus so they require a click to display)

(stretch goal) to see whether we can remove the jquery dependency from the main.js file that is loaded into every page - this would also mean replacing the footer and other parts of the wiki page with React-based alternatives.

Acceptance criteria

Wiki pages loaded through the new endpoint (see issue #965) have a React-based header
The menus in the header do not appear on hover!
We have synthetic page load data comparing the new header to the old header

Why does everything seem to need to be written using React these days?
It honestly feels like trying to fit a square peg into a round hole to me at this point.

@ExE-Boss: some of our reasoning for using React is captured in this ADR: https://github.com/mdn/mdn/blob/master/ADRs/001-use-react.md
In my experience, React makes front-end development easier. We anticipate having to do a lot of it in 2019, so trying to move to React now will increase our development velocity for the rest of the year, we  hope.

I would also like to point toward hyperHTML, which I didn’t see mentioned on the page.
https://medium.com/@WebReflection/consider-hyperhtml-before-replacing-anything-154a2104d6e3

FWIW, W3C Respec has been using hyperHTML for more than a year:
https://github.com/w3c/respec/blob/develop/package.json#L92
And ABP ships with HyperHTMLElement and hyperHTML to roughly 100M users, targeting FF, Chrome, Opera, and Edge 👋

Just my 2c, as someone involved with browsers and standards for the last ~13 years. Libraries come and go, and generally all libraries/frameworks have a lifespan of about 5 years (there was some data published by GitHub about this, I believe, that made a pretty compelling case). In evaluating a solution, be sure to consider the library dying out or becoming a maintenance burden after 5 years (e.g., everyone trying to get off jQuery onto Web Components).
In the case of ReSpec, we chose HyperHTML because it's "so close to the metal", super thin and - it's extremely standards conforming and a library that can be used without build tools, and could easily be used for another 10 years with no problem.
Before choosing React, or any library, please consider if the MDN project will be around in 10-20 years (I believe it will be) - so these technology choices REALLY matter. Please choose wisely.

If you feel the need to do something with the header in JS, then I would opt for a WebComponent based approach and, if using React, wrap the React in https://github.com/rstacruz/remount to make it a WebComponent.
That way the rest of the site don't have to care whether it's React, LitElement, vanilla WebComponent or whatever and you can independently update and/or replace component implementations independently from one another without any of them having any other public API than the webcomponent they are exposed as.
We're taking this approach at our sites as we recognize that some highly dynamic parts would benefit from something like React, but we don't want to require React on page loads with no such highly dynamic parts and don't want to couple all of our code to a single library.
Combining such a structure with something like Webpack and code splitting enables standard webcomponent based interfaces, sharing of libraries between webcomponents as well as  loading of heavy libraries only whenever a webcomponent requiring that library is used.

WHYYY!? Why React! Why not web standards!? Why not Web Components? It's a shame.

Web Components/Polymer
Web components will eventually be the standard component system for the web, and in that sense they seem like the best choice for Mozilla. But they are not yet well supported by browsers other than Chrome, and so we would have to adopt the Polymer framework.

This is simply untrue and somewhat disappointing reasoning; web components are supported by all major browsers*. The Polymer Library has been put in maintenance mode, but there's a wealth of web component libraries out there now, LitElement, Ionic, etc.

If we didn't have such ambitous goals for 2019 and weren't expecting to work with contractors on those goals, I would want to seriously consider using Web Components because they seem like the best solution for the open web. But the lack of tools, ecosystem, and developer community makes this a non-starter for now.

I agree that the web component ecosystem isn't as large as React's, however we've been doing a bunch of work to improve this situation and make things easier for developers on any scale: www.open-wc.org
I feel like it's a little disappointing, especially from MDN, to not go with web standards. I do hope you reconsider.

Edge when they switch to chromium

Looking at the MDN header, there is a perfect use case for <mdn-submenu> Web Component.
It currently does not work with "disable javascript" feature, so there won't be any regression.
You could avoid using Shadow DOM for such a small thing, and only use Custom Elements part of the standard, same as GitHub does (which would make a lot of sense for this particular case).

As representatives of Mozilla, standing for and promoting the use of open web standards, we should be more diligent about our choice of technology. It comes under increased scrutiny and it sets an example to the people we intend to educate on the importance of open web standards.
It's not that React is bad. We use it elsewhere on other properties as mentioned here. But for MDN itself, choosing to overlook Web Components, which as commenters above point out has widespread support, impacts our message.
This React rewrite looks like an experiment for now. Which is good. Learning is good. But I echo @marcoscaceres' thoughts and sincerely hope you'll consider carefully the implications not just the how when approaching the MDN rewrite.
Regardless of the technology used now, it will be eventually rewritten in the future. Frameworks come and go. Being closer to the web platform matters more in the long term.

I'm a huge fan of MDN, and vigorously support your work.
In addition to all the above:
Inherent Benefits of WC Over React
All the reasons that the Firefox browser-chrome team is reimplementing UI in web components apply here. Why limit yourself to the performance of react.js?
Pedagogy
When users read MDN, and they open the inspector, let them see idiomatic web code, not what JSX and VDOM diffs compile to.
Developer Experience
All the cited DX benefits of using React are available in web components-based libraries, and there are many to choose from, whether you go with Google's lit-element or with community libraries like hybrids or hyperHTML.
So we all agree that components that render DOM as a pure function of state are a great way to develop. So, the best resource on the web platform should do that with the web platform.
React Approach Hostile to Web Standards, Thus Inappropriate for Mozilla
React fails more https://custom-elements-everywhere.com/ tests than any other framework. React's ethos is very much against the use of Web Components and the platform in general, at the moment.
React's approach very much aligns with the view that the web platform is a problem to be worked around and abstracted over. In the "react way", the browser is merely a compile target - one of many among native apps, etc. I don't think Mozilla should be encouraging that view by encouraging the use of React.
Lastly, it strikes me (personally) a little funny for Mozilla to investing so heavily in Facebook's tech stack.
React is a fine library, but using it on MDN just strikes me as odd.

@davidflanagan I think it's perfectly fine to choose React for a project, so I don't want this comment to seem only anti-React or only pro-Web Components, but I noticed in the ADR some incorrect information around Web Components, and it would be a shame if a decision was based on false background.
Specifically:

Web Components/Polymer

Web components will eventually be the standard component system for the web, and in that sense they seem like the best choice for Mozilla. But they are not yet well supported by browsers other than Chrome, and so we would have to adopt the Polymer framework.
Unfortunately, this whole paragraph is basically untrue. It seems like it was written based on information from 2 years ago.
Web Components (<template>, Custom Elements, and Shadow DOM) are supported in Chrome (and all Chromium browsers like Opera, Android, and Samsung), Safari, and Firefox. Safari has had support for almost 2 years, and Firefox since 63. Firefox is porting it's actual UI from XUL to Web Components as we speak.
Also, Polymer is far from the only option for writing web components. Stencil (from Ionic) and SkateJS (which can use Preact, React, or lit-html to author components) are two popular libraries. Angular, Vue, and Svelte are working on Web Component output. The Polymer Project itself just released LitElement, which is a very React-style approach to writing web components, but without any proprietary JS syntax extensions or required build steps. I encourage you to check it out if you like the React experience and are even the slightest bit interested in Web Components in the future.

If we didn't have such ambitous goals for 2019 and weren't expecting to work with contractors on those goals, I would want to seriously consider using Web Components because they seem like the best solution for the open web. But the lack of tools, ecosystem, and developer community makes this a non-starter for now.

What tool support are you looking for? Projects like LitElement have great tool support because they're just JavaScript libraries. There's no special syntax or build requirements, so they work with all the existing tools like Webpack, Rollup, Parcel, Babel, ESLint, TypeScript, Workbox, etc...
Older versions of Polymer used HTML Imports instead of JavaScript modules, and therefore had to have custom tools or plugins. This hasn't been the case since Polymer 3.0 though, and Polymer is also now compatible with all the standard ecosystem tools.
I really hope that the ADR can be corrected to reflect the actual state of Web Components, and that the decision here, even if it's to move forward with React, can be based on accurate information. I'm glad to help in any way that I can.

I'm glad to help in any way that I can.

Ditto. I'm ready and willing to help implement with lit-element or another modern web component library.

I would personally prefer to use hyperHTML or lighterHTML since they have a few extra features that lit‑html lacks, which my code depends on.

I can help with code using hyperHTML i think is the best route

Since we're proposing standards based alternatives, and since the React choice looks to me somehow rather motivated by boredom of using just standards, here my counter list:

wickedElements, repo and post, are 100% standard based, resembling the Custom Elements API, working down to IE9 and all other Desktop/Mobile browsers, all through an innovative paradigm and all in 2KB library that requires zero polyfills
Neverland, repo and post, is like developing with React and hooks without needing any compiler step
lighterhtml, repo and post, is a simplified hyperHTML like primitive that can be used with any kind of custom hooks, including haunted, which is already compatible with both lit-html and hyperHTML, augmentor to create your own custom hooks, or TNG-Hooks from, IIRC, your former colleague Kyle Simpson
HyperHTMLElement which ships with ABP in production to million users daily, and it's been stable for a long time (same as hyperHTML, they both came out prod ready more than a year ago)

All these variations based on Web standards, and delivering just those, are the attempt of a long standing Web standards promoter as I am, so that surrounding hype can easily lower when you see you can achieve great results simply respecting, and using as much as possible, the Open Web Platform, the one Mozilla should have as part of his mission.
Please do not ever ditch the platform on a site that promotes it.
Thank you.
P.S. obviously happy to help as I can if it's needed 👋

lighterHTML is basically hyperHTML 3.0.

There’s a PR for adding React as a dependency to Kuma now: mozilla/kuma#5250 😞

React makes front-end development easier.

Ease of experience for developers should not trump the experience of end-users. The added code-weight, complexity, and chance for things to fail are strong reasons to serve up as much in good old HTML as possible. Maybe a SSG augmented with some light JS?

I should add, I'm all for ripping out jQuery from things. But these days, some progressive enhancement, native JavaScript, and polyfills (automated, even, from polyfill.io) do a lot.

I won’t comment on the rest of this thread. But the notion that React is somehow antithetical to standards is very misinformed.
We’re thrilled to collaborate with vendors on specifications that advance the future of the web. That includes ongoing work on user interface responsiveness, display locking, main thread scheduling, and other initiatives like virtual scrolling APIs. Some of these collaborations are currently driven by Chrome but we’ve worked with Mozilla, Apple, and Microsoft too on the topics where they were interested in our input. Having worked on React, we’ve accumulated some experience that we are excited to share with the broader web community.
There are valid criticisms like subpar support for custom elements, but again, it is not due to a lack of care. Rather, there are many unsolved questions that even the web components community can’t reach agreement on. (Related to heuristics for properties/attributes and server rendering.) We take API changes in React very seriously so we want to make sure that if we change the behavior, we won’t have to change it again in a few years. I hope that you can empathize with such approach. You’re welcome to contribute to the discussion about specific issues on the React issue tracker.
We care about moving the web forward, and not just React alone. We don’t always agree about which specific standards or techniques will help folks create better user experiences for the web. That is a source of much tension in some communities. But don’t mistake disagreements with a lack of enthusiasm. React is firmly built on the web platform and standards, and will continue to be.

Rather, there are many unsolved questions that even the web components community can’t reach agreement on. (Related to heuristics for properties/attributes and server rendering.)

That's one way to put it. Another way is that we can't get agreement on heuristics because heuristics are bad and it would be great if users could just specify whether they're setting an attribute, property or event handler in JSX. Framing this as the web components communities failure to agree is misleading, IMO.

@gaearon I don't think any of the above is criticising React or is necessarily misinformed. It's simply pointing out that it isn't required in this instance. It's like using a steel-mill hammer to knock a thumb-tack into putty. Sure, it'll work – and it might be the most poweful hammer in the world – but it's overkill.
Tools like React (and your own tool, Redux) are great, but there is a creeping tide of people using tools like it in places that it simply isn't required, or appropriate. A big part of this is down to people working on projects it isn't required on feeling like they're being left behind, rather than recognising they are working on projects that don't need it, as well as people working with the tool irresponsibly praising it without noting where it is appropriate to use it.
Sites like MDN are a standard bearer for technologies that are used on content-focused websites like itself. If we start adding React for reasons related exclusively to the development experience, then we risk sending the message people should be using React for other content-focused websites.

Thanks for the constructive comments everyone. I'm glad to hear that web components are more viable today than I realized. I'd love to have the opportunity to work with web components. But that is not an option for MDN.
The MDN engineering team is very small, but we have ambitious goals for 2019. (These goals are not yet ready to share here, so you'll just have to trust me on this.) We're expect to be doing a lot of front-end work this year, and also expect that we're going to have to hire contractors to help with this. There are likely to be an order of magnitude more webdevs with top-notch React skills than we would be able to find for web-components based solution.
It is not like we've just made the decision to switch to Flash! Nor are we announcing that we're going to start using closed-source solutions for our front-end work. Instead, we're picking  a technology that we believe will allow us to most quickly deliver features to our users. And that has to outweigh concerns about the purity of the solution.
The particular user story that this thread is one of the things I'm working on this month. A kind of proof of concept, to see if I can determine the performance impact of replacing the jquery library with react, and to figure out whether we're going to have to jump straight to server-side rendering before we ship anything React-based.  If it turns out to be an utter failure, then we'll reassess.
The point here is to improve our user's experience with MDN. We're not going to let MDN turn into a big bloated thing. Your trust would be appreciated.

Sites like MDN are a standard bearer for technologies that are used on content-focused websites like itself. If we start adding React for reasons related exclusively to the development experience, then we risk sending the message people should be using React – or other similar tools that are intended to solve problems complex web apps suffer from – for other content-focused websites.

I agree with this, and I also want to add that MDN is a website specifically for web developers, and by being made using standards, it's currently very easy to just right‑click and select “Inspect element” and have it just work without needing to install a 3rd party DevTools extension for the browser to be able to understand React’s VDOM.

Hi @davidflanagan - thanks for the thoughtful response!

We're not going to let MDN turn into a big bloated thing. Your trust would be appreciated.

Apologies if this felt like a criticism of you personally. Rather, it's a comment on React as a platform itself. I trust you to do the right thing, but React is a big beast with a mountain of front-end baggage attached.
As a side note, starting this thread with "so I can gain experience using React" probably gave people the impression the motivation here was for learning purposes rather than for any meaningful gain to MDN as a platform.
Thanks for adding more details.

@gaearon for a second, imagine this wasn't about React, and the TL;DR version of this story is:
We're refactoring a working "vanilla" jQuery to bring in a framework that needs mandatory transpiles steps due non standard syntax (JSX, not Babel), a framework that easily ditches semantics (div all the things) and simplifies inline style per element, on the #1 stop to learn about Web Standards.
How would that feel to you?

How does this affect the accessibility story?

@WebReflection

bring in a framework that needs a mandatory transpilation step due to non standard syntax

@kenchris Probably not in a good way, given React’s obsession with using <div>s everywhere.

@davidflanagan would it be possible to update the ADR though, especially the section on web components?

FWIW, React can be accessible. It just has a well-earned reputation for doing so terribly because... defaults and developers?

@davidflanagan

And that has to outweigh concerns about the purity of the solution.

Apologies 'cause I'm sure you mean well but this reads to me like:
We're a green company but since we have big plans for this year we're ok if everyone working for us uses 1 car to reach out office daily.

I have opened https://github.com/mdn/mdn/pull/58 to correct the section about WebComponents and put extra emphasis on the fact that Firefox is using them for the UI now.

@davidflanagan also regarding SSR. Custom elements naturally work with static pages, CMSes, and classically server-rendered pages. This removes a lot of complexity around the server side of the app, and questions about how to mount frameworks components into an otherwise markup (or markdown) driven page.
With web components you can just add them to markup:
<body>
  <mdn-header>
    <h1>MDN web docs</h1>
    <mdn-menu>Technologies</mdn-menu>
    <mdn-menu>References & Guides</mdn-menu>
    <mdn-menu>Feedback</mdn-menu>
  <mdn-header>
  ...
</body>

Modern web component libraries are small enough (~5k for LitELement) and fast enough (faster than React typically) that you basically don't have to care about "deep" SSR with this setup. Aside from adding the scripts that implement the elements, it probably requires little to no changes to your CMS.

How does this affect the accessibility story?

React lets you create fully accessible apps. If anything, React helps you do that because the component paradigm lets you write pieces of UI that enforce accessibility best practices and avoid regressions.
We have some guidance on that here: https://reactjs.org/docs/accessibility.html
There are many React projects that treat accessibility with the priority it deserves, and help developers achieve better outcomes:

https://reach.tech/
https://github.com/downshift-js/downshift
https://www.npmjs.com/package/eslint-plugin-jsx-a11y

Quoting David:

Case in point: Our pattern library exposes buttons and form fields as reusable components. It requires effort to make an implementation inaccessible. https://www.starbucks.com/developer/pattern-library

Of course there are teams who ignore all of that. Ultimately, whether your app is accessible or not has more to do with the priorities of your team, and even using React won’t help you if you don’t care about your users.

Probably not in a good way, given React’s obsession with using <div>s everywhere.

This FUD is especially interesting because React was (one of?) the first mainstream component libraries that implemented fragments — returning multiple nodes from a component without extra wrapping or need for extra divs.

Probably not in a good way, given React’s obsession with using <div>s everywhere.

This FUD is especially interesting because React was (one of?) the first mainstream component libraries that implemented fragments — returning multiple nodes from a component without extra wrapping or need for extra divs.

Ok, this isn’t really a fault of React per se, but the fault of React based projects I’ve seen out in the wild.

Ok, this isn’t really a fault of React per se, but the fault of React based projects I’ve seen out in the wild.

You could say the same about jQuery projects or, really, anything that’s popular.  Presumably, MDN developers care? :-)

We're refactoring a working "vanilla" jQuery to bring in a framework that needs mandatory transpilation step due to non standard syntax (JSX, not Babel which aim is to fix standard gaps), a framework that easily ditches semantics (div all the things) and simplifies inline style per element, on the #1 stop to learn about Web Standards.

“div all the things” is a strawman argument that has nothing to do with React (as you can see from https://github.com/mdn/sprints/issues/967#issuecomment-463290568). Repeating it doesn’t make it any more true or advance your argument.
You can use React without JSX, which some Mozilla projects happily did. For example, the highly successful (as far as I know) Firefox debugger rewrite in React. HTM is a nice syntax sugar for that which uses tagged literals.

All in all, I’m not here to advocate for React. Just wanted to highlight some common misconceptions and mention that we’d be happy to answer questions about React if you have any. Cheers.

I agree with this, and I also want to add that MDN is a website specifically for web developers, and by being made using standards, it's currently very easy to just right‑click and select “Inspect element” and have it just work without needing to install a 3rd party DevTools extension for the browser to be able to understand React’s VDOM.

This argument is also repeated in this thread. I want to point out that "Inspect element" works perfectly fine in React apps. React produces regular DOM nodes, and that's what you see in the inspector.
There do exist approaches that favor the user (e.g. minification of CSS class names) over the casual developer and tinkerer. They might make sense for some consumer apps, but I think those would be a worse tradeoff for MDN, and wouldn’t recommend them.
If MDN were to use React, I think it would be ideal if the DOM output was clean and easy to inspect by hand. That’s easy to accomplish with React — just as easy as with Vue or another popular UI library.

Hi @davidflanagan, I appreciate your willingness to hear feedback here.
I think one thing that is not being discussed here is the value that comes from dog-fooding web standards as a company that builds a web browser. You'll not be able to improve web APIs if you don't use them. Yes, React of course uses web APIs but they are for the most part abstracted from you.
One thing I always admired about Mozilla, thinking back to the Boot 2 Gecko days, is how everything they worked on cycled back to improving the web platform. It would be a shame if Mozilla starts using heavy abstractions that prevents them from doing that.

There are likely to be an order of magnitude more webdevs with top-notch React skills than we would be able to find for web-components based solution.

Any developer that understands react components can write components with lit-elements. The concepts are totally congruent.
In fact it's easier to write styles in shadow dom than it is to use css-in-js.

You can use React without JSX, which some Mozilla projects happily did. For example, the highly successful (as far as I know) Firefox debugger rewrite in React. HTM is a nice syntax sugar for that which uses tagged literals instead of JSX. So that’s an option too. React is pretty flexible.

If you don't use JSX but use HTM, which needs a mandatory transpilation for production, it's the same, that's not the platform.
Moreover, HTM uses same non standard syntax for feature parity with JSX, and the fact HTM uses template literals simply shows the power of the platform, where projects like hyperHTML or lit-html mastered the template literals technique in a way that makes HTM look like a double indirection of what the platform could do already.
Beside all this, we all come from an era where looking at the source code of a page would lead to a learning experience.
React and every other framework that takes the standard away from the implementation makes learning from source code impossible.
MDN is all about learning, and lighterhtml, as well as hyperHTML or lit-html, would reflect their templates as they are on the live, inspectable, source of the page.
Same would go for Custom Elements too.
In a site famous for letting devs and New comers learn from the platform, I think it's unacceptable to use hard abstractions that would make learning from the source super hard.

From the doc

But the lack of tools, ecosystem, and developer community makes this a non-starter for now.

In the future maybe we'll be able to use Web Components for small components, and tie them together into larger components with React.

The above rationale suffers from risking the absence of web-standards being a self-fulfilling prophecy.
It is absolutely unacceptable that an open, web-standards-delivering company opt for highly proprietary, opinionated framework from a morally questionable company in lieu of trailblazing the standards you are tasked with delivering and evangelizing.
Not a great tooling? Not a great community? Have some skin in the game and help create it. I would love to see more open standards. MDN's planned adoption of React is a step back.
I am just one developer, but any hopes you may have of "winning" me over as a user or supporter of Mozilla are, as of this writing, dashed to the rocks.

There are valid criticisms like subpar support for custom elements

That's a bit like saying there's subpar support for library/framework x until you add the requisite javascript libraries, isn't it?  Custom elements, at least, do not need any requisite libraries in most cases.  For the remaining cases, the fallback lightweight polyfills are done quite well.
It sure is nice to be able to do things like this and have them work:
    document.body.appendChild(document.createElement("hello-world"))

It seems like framework/"library" authors ought to eventually look at their specific component models as a different-flavored base-class for making native custom elements.
Kind regards

The MDN team made our decision about React last sprint. This sprint we're trying to figure out how we're going to put that into practice. This github issue was intended to be the place where I tracked some of my work this sprint. If you want to understand it in context, you should probably also look at issue #965, issue #966, issue #968 and issue #969. (Though I would appreciate it if you would not carry this conversation over into those issues.)
You all are welcome to continue debating React vs Web Components here, if you want. But know that I've muted email notifications and I don't plan to respond to most of the comments.
The decision to use React was made for the pragmatic reason that we believe that our tiny team will be best able to move quickly and deliver features to our users with React. There are many good things about Web Components. But given the ambitious goals that the MDN team is tasked with this year, they are not the right choice for us.

Looking at the linked issues and https://github.com/mdn/mdn/pull/53/files#diff-992ca475abeb0c101165f19ff62d37e7R136 about Flow

Half the MDN frontend team already has experience with Flow, but no one on the team has experience with TypeScript
More Mozilla projects use Flow than use TypeScript. The projects using TypeScript seem to be smaller and newer
Flow is more like a linter that checks types and strips type annotations leaving standard JavaScript.
TypeScript is more like a compiler for a new language. If we were to choose TypeScript we'd also
have to decide which of its non-standard language extensions we will use and which we will not allow.
Fundamentally, it seems wrong to me for Mozilla (the spiritual home of JavaScript) to be starting projects   using a language that includes non-standard (and not on a standards track) extensions to JavaScript. As Brendan Eich says "Always bet on JavaScript".

This looks like being the wider context.

Hey @davidflanagan that snoozed his own thread:

#968 doesn't need React
#969 needs a change in your servers (time + money)
You can test both #965 and #966 in your localhost

Recently MDN is showing some bigger than usual banner, rightly asking for contributions, and I've always been keen to that, when it comes to projects that matters (ArchLinux, GNOME, and Mozilla are indeed in my usual payed contributions portfolio).
Since I don't get to even be listened to in here, I am not willing to contribute to this madness, neither as a content editor.
Feel free to revoke my rights, andI wish you best luck with all this 👋

@veikkoeeva Ironic that Custom Elements weren't chosen because the community is too small and tech too new/unfamiliar.
Then the team chooses Flow. A rather inconsistent line of reasoning.
It really sounds like there are some React kool-aid drinkers over at MDN, and that this is about someone's favorite toy instead of a fact-driven conversation.
If the decision was based on a mix of standards compliance, tooling, community, performance, it seems that Angular would have been the way to go, not React + Flow (Sure, Angular is less popular than React, but it is my no means small or niche).

The decision to use React was made for the pragmatic reason that we believe that our tiny team will be best able to move quickly and deliver features to our users with React.

As a user, I would like see Mozilla that uses web standards to promote web standards.
As a developer, I would like see Mozilla and  their developers using web standards and promote them. I don't need to see the nth React project.

Mozilla has been quite active in advocating the diversity among browser vendors when Edge announced moving to Chromium.
Please compare this with the current case when MDN developers are going with the mainstream framework and do not advocate the diversity anymore.
I have to admit that React has wide adoption for reasons. But now, thanks to such opinionated decisions, it is at risk of becoming a "standard de facto".

As a developer that pushes for selfdogfooding, the use of React will be antithetical to Mozilla providing a place for documentation and demonstration of Web technologies. It'd actually help the act if instead the site was done with WebComponents directly and add potential examples of how React can be used in the documentation (not in the source thereof). Thankfully, the site is an open Wiki of likes so we can extend what we needed.
We should see React as an extension of what the browser has to offer; not as an authoritative representation thereof.

Do you all think that forcing them to use an isolated dom node through orchestrated social media outrage will change that web components might just not be the future as the wider community has ignored it and will continue to do so? Sometimes it feels like you forget that we all decide what becomes a standard, and the majority isn't going to adopt specs that fails to perform, as has happened countless of times before.

@davidflanagan If you're going to rewrite MDN using React I assume it's going to require enabled JS to render any content so it would make it impossible to obtain any content as a static data which is sad by my opinion. It can be solved by Server-Side Rendering (SSR). If you haven't planned implementing SSR by yourselves I'm offering my help with that (since I'm experienced with that) as a volunteer. I could afford some time to at least produce a backbone for SSR. Feel free to contact me if it would be a good idea.

Thanks for offering @unclechu. One of our goals this sprint is to at least try SSR. I have not set that up before, and would welcome some pointers. To start, however, we're going to have a little bit of react inside of jinja templates, and I don't know whether SSR can work in that situation.
Once https://github.com/mozilla/kuma/pull/5254 lands there will be something concrete to try rendering on the server, if you want to take a stab at it!

I think that this is some really great discussion, but people are having a hard time separating their experiences and heresy from fact about "the other side". "Div everything" is as standard for developers as seeing <some-component> in the DOM is semantic.  Neither side is "right" and both React and Web Standards are as likely to change in three years as the other.

I will, however, leave this here for people to pontificate upon... 2018 State of JS (web components, in general, are under the "Other" page...)

@davidflanagan

To start, however, we're going to have a little bit of react inside of jinja templates, and I don't know whether SSR can work in that situation.

React doesn’t work all that well with Jinja and other non‑JavaScript SSR solutions well from my experience.
This is because there’s no React for Python, and React works using its VDOM, whereas Jinja2 and similar assume that they’ll be outputing pure DOM, which is a bit difficult to wire with React.
But if you really want to use React, I at least recommend using https://github.com/rstacruz/remount, which creates a React environment inside a Custom Element, so that React doesn’t leak into non‑React scope, which is a possibility.

In context of backend html rendering using Python I could propose this possible solution for this:

Writing a process in node.js (with React SSR stuff inside) which reads something like JSON-commands from stdin and returns to stdout rendered html code using React SSR;
Starting that process from Python as child-process permanently;
Asking from Python main process to render something from node.js process and reading result from stdout.

Also it would be better to run few SSR workers and balance requests between them. Maybe there's some python lib to serve such queues? Or as an alternative we could run SSR processes (workers) as a local-hosted HTTP-servers and balance them with local nginx-proxy, and from main Python process request renders via HTTP. But of course using HTTP layers adds some overhead and forces us to control SSR-workers apart from main Python process.

React makes front-end development easier.

We need to make user experience easier, not development.

The MDN engineering team is very small, but we have ambitious goals for 2019. (These goals are not yet ready to share here, so you'll just have to trust me on this.) We're expect to be doing a lot of front-end work this year, and also expect that we're going to have to hire contractors to help with this. There are likely to be an order of magnitude more webdevs with top-notch React skills than we would be able to find for web-components based solution.

While I respect your decision (you understand your needs/constraints better than I do) I find it sad that web standards are being over looked for custom frameworks.
In particular the statement here(highlighted in bold) made me sad.
This means you are doing the same thing other companies are doing and overlooking Web components for React; Systematically alienating the standard for a custom tech which becomes self-perpetuating. If we don't use these technologies at scale we dont uncover the problems and learn how to fix them. Every time a large entity in a privallaged position chooses custom tech over the standard it takes us one step closer to a non-standardised world.

MDN is going to React???? The day you can't hit "View Soucre" and see human readable data on Mozilla web documents will be the day the Manifesto truly becomes meaningless
I'm not angry really sad. MDN is supposed to be the model of web standards.
Mozilla employees are like frameworks they come and go but HTML is forever. Choosing a framework because a team knows it wrong.
You need to be hit "view source" and read not see a much of scripts. Greg McVerry. I know folks say well MDN code will be available in the repo. In my browser window when I hit view source, if the mission is  equity and access....sayign "here's the repo" is not the same. Mozilla teachers throguh source code not frontend frameworks
As a contributor to MoFo and MoCo I have seen this story play out and always looked to MoCo and MDN with the commitment to HTML first as a north star
MoFo would be all about the latest and greatest framework trying this and that making resources harder and harder to remix (they very essence of what being open means) while MoCo always held firm. Always stayed committed to an open human readable web.
I worry those days are over
Look at MoFos track record of developing software and platforms literally every single one is gone and failed. Look at anything Mozilla has done in HTML. It is still there. Forever
Every existing product built on REACT is a MoFo project and almost every single one is marked for sunsetting and deletion.....
We have enough data to know this is a failed path. Like every time we tried.
Go read the top reason for choosing React:

David has 18 months experience with it; Schalk was already learning it.

Choosing to abandon the open web because one person on staff knows it is a bad idea. Employees will not last longer than HTML.

Web components will eventually be the standard component system for the web,

NO! Web components ARE  a standard and an OPEN standard. They only survive in the face of corporate greed when Mozilla stands up.

The MDN has ambitious goals for 12019 that we can't share.

When did Mozilla lose its attitude to open? This shift to React and away from the open we reflects a turn away from open contributors and a disdain for Mozillians who want to contribute. We are just seeing another example of Mozilla turning our back on the Manifesto.
I mean @davidflanagan MUTED HIS OWN THREAD basically saying we don't care what the community thinks. We are Mozilla we make software FOR open source contributors but we no longer have any desire TO BUILD with open source criteria.
I know the team feels JQuery and javascript present limited choices fro complicated UI (so use less), and I won't hype web components more than they are. , I struggle with front end design as well battle every, but I made a promise to the open web. Mozilla should do the same.
We need to work together but r to make it better using open standards in a web first way, will always support MDN...but just hope I can still click "view source" and not see gobbily gook

I'm really happy to see the MDN team making decisions and documenting their process in public ♥
It's really disappointing to see the pile-on in this thread about their decisions 💔
I wish success to the MDN team, and look forward to seeing what 2019 brings (it sounds exciting 🤩).
⚛

MANY OF THE PEOPLE IN THIS THREAD SHOULD BE ASHAMED OF THEMSELVES
The MDN team has built the single greatest resource on the web for web developers. Thousands if not tens of thousands of hours of work have gone into building it. And this is somehow not enough for you?
 We should offer every ounce of support our sorry asses can possibly muster for any effort by the MDN team to make their lives easier.

Imagine Brendan Eich using TypeScript so that nobody would keep betting on JS.
The message that the #1 resource for Web development is ditching the same Web technologies it advocates, would be as disastrous as that, implicitly claiming a defeat for the Web, hence a seppuku in the long term for the platform nobody would care much anymore.
When MDN used jQuery to create anything, the Web was in an objectively poorer state.
Choosing in 2019 frameworks after all the innovation and effort put in browsers alignment with standards, doesn't sound rewarding for all the people that contributed with the MDN content that explains all these new amazing opportunities to develop through Open Standards.
I don't even care if MDN would use any of the libraries out there, quite the opposite, I actually would love to see it embracing raw Custom Elements like never done before, so please think about the heavy repercussion this decision would have.
This is not about React per se being a bad tool, this is about every Web Standards advocate that would indeed feel ashamed at pointing at a resource that didn't use its own product.
If using frameworks is instead seen as mandatory due big plans, then please stick on this header: "whatever you'll learn here won't be useful on the real world unless you are a React core developer" so that people can change site and learn something more useful instead for their own career sake.
Thanks for considering improving the message, rather by going custom elements, or explicitly stating above sentence in every page.

Imagine Brendan Eich using TypeScript so that nobody would keep betting on JS.

Literally search "brendaneich typescript" and you can see him advocating TypeScript again and again. He also helped spec WebAssembly and modified "always bet on JavaScript" to "always bet on JavaScript/WASM"
This whole argument is just incompressibly stupid, mostly because it's entirely inauthentic.

Here, meet the mighty Brave browser and see they use JavaScript.

He also helped spec WebAssembly and modified "always bet on JavaScript" to "always bet on JavaScript/WASM"

I have helped with other specs for JS, not sure I understand your point there ... WASM is also not code for developers to learn or write, so again, what is this reply about?

Andrea just has been salty about React for years because ...

I've worked at Facebook with the team that published React later on. I know React before you could know it existed. If you'll ever be interested in knowing why, at its debut, I hated React, I'd be happy to explain it to you, but differently from the React tribe, I've never made it personal, and I'd never shame anyone or anything in public.

... because he'd prefer people use his stupid libraries.

And again, premium for the genius of the day goes to you, right?

Every single library I've written has been to promote the usage of the platform for every skeptical thinking the platform wasn't fun, wasn't capable, wasn't ready.
Glad other projects followed up, see lit-html, as example, and glad not everyone is as immature and irrespecutful like the last two developers from the React community.
Best Regards.

@WebReflection Please don't say this:

The attitude of the React community full of insults and bullying is, instead, super mature.

That person always have a bad attitude at everything and it is not a representation of the React community.

@montogeek I have pointed at a whole twitter thread started from a Facebook employee full of even worse attitude and bullying than the one you found in here.
Their representatives should lead the way not only from a technical point, but from an ethical one.
If there were a moderator, those two message would be either edited or removed.
I'll correct that sentence regardless, but the feeling remains.

In context of backend html rendering using Python I could propose this possible solution for this:

Really? All of this to output basically a content site?
Even if considering only client side, React without its ecosystem is not very useful. So i would not be surprised if MDN will depending on redux, react-router, a third party datetime/search component etc

David has 18 months experience with it; Schalk was already learning it.

The learning curve to using web components is pretty flat, since is just standard JS class with a few callback hooks, everything else can/should be accomplished with native web platform, so i don't see React proficiency as a strong argument
All in all just like to highlight a recent article on Mozilla Hacks, by @potch, calling developers to unleash the power of web components:

Custom Elements have already been used to make it easier to build VR content on the web, spawned multiple UI toolkits, and much more. Despite the long standardization process, the emerging promise of Web Components puts more power in the hand of creators. Now that the technology is available in browsers, the future of Web Components is in your hands. What will you build?

If web components are not suitable to a primarily content site, with a few dynamic interactions it should be for my complex app?
If web components are so hard to be proficient in (more than a non standard, own world library) should i really invest in it?
So, Mozilla does not believe in what they write?
In my opinion, none of the above statements about web components are true but sadly this is the message Mozilla is passing to web developers with this decision

Can we have a discussion about the pros and cons of the approach to design
without devolving into personal attacks?
I would recommend either closing this issue or removing the posts that
violate our CoC.
On Fri, Feb 15, 2019 at 8:04 AM Luiz Américo<EMAIL_ADDRESS>wrote:

In context of backend html rendering using Python I could propose this
possible solution for this:
Really? All of this to output basically a content site?
Even if considering only client side, React without its ecosystem is not
very useful. So i would not be surprised if MDN will depending on redux,
react-router, a third party datetime/search component etc
David has 18 months experience with it; Schalk was already learning it.
The learning curve to using web components is pretty flat, since is just
standard JS class with a few callback hooks, everything else can/should be
accomplished with native web platform, so i don't see React proficiency as
a strong argument
All in all just like to highlight a recent article on Mozilla Hacks
https://hacks.mozilla.org/2018/11/the-power-of-web-components/, by
@potch https://github.com/potch, calling developers to unleash the
power of web components:
Custom Elements have already been used to make it easier to build VR
content on the web, spawned multiple UI toolkits, and much more. Despite
the long standardization process, the emerging promise of Web Components
puts more power in the hand of creators. Now that the technology is
available in browsers, the future of Web Components is in your hands. What
will you build?
If web components are not suitable to a primarily content site, with a few
dynamic interactions it should be for my complex app?
If web components are so hard to be proficient in (more than a non
standard, own world library) should i really invest in it?
So, Mozilla does not believe in what they write?
In my opinion, none of the above statements about web components are true
but sadly this is the message Mozilla is passing to web developers with
this decision
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mdn/sprints/issues/967#issuecomment-464043715, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKC-pksCLYL1ZvfIRE8QFMSNB-XUBuXYks5vNrBbgaJpZM4amRE9
.

@WebReflection

I've worked at Facebook with the team that published React later on. I know React before you could know it existed. If you'll ever be interested in knowing why, at its debut, I hated React, I'd be happy to explain it to you, but differently from the React tribe, I've never made it personal, and I'd never shame anyone or anything in public.

I’m interested in hearing about it, but you probably should make it a post on your blog, rather than a comment here.

Someone want to help me find Brendan Eich on this list? https://github.com/brave/brave-browser/graphs/contributors
Also apparently Brendan Eich thinks we should all use C++ because apparently the code other people write is more indicative than his own words https://github.com/brave/brave-core

Can we have a discussion about the pros and cons of the approach to design without devolving into personal attacks? I would recommend either closing this issue or removing the posts that violate our CoC.

As a reminder, the Code of Conduct for this repo references the general Mozilla Community Participation Guidelines (CPG) and the specific Developer Etiquette Guidelines (DEG).
The CPG includes the following:

Direct but Professional
We are likely to have some discussions about if and when criticism is respectful and when it’s not. We must be able to speak directly when we disagree and when we think we need to improve. We cannot withhold hard truths. Doing so respectfully is hard, doing so when others don’t seem to be listening is harder, and hearing such comments when one is the recipient can be even harder still. We need to be honest and direct, as well as respectful.

Understand Different Perspectives
Our goal should not be to “win” every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas better. Strive to be an example for inclusive thinking. “Winning” is when different perspectives make our work richer and stronger.

Personal Attacks
Conflicts will inevitably arise, but frustration should never turn into a personal attack. It is not okay to insult, demean or belittle others. Attacking someone for their opinions, beliefs and ideas is not acceptable. It is important to speak directly when we disagree and when we think we need to improve, but such discussions must be conducted respectfully and professionally, remaining focused on the issue at hand.

The DEG also recommends "No whining about decisions" (though in a different context).

@jmswisher thanks for the concise reminder and summary.
If I can clarify anything, at least from my side, is that decisions have been taken not in the public, and this is the first public place to communicate our concerns about such decision, made over an outdated, and misinformed, ADR document.
Mozilla employees have of course the right to do whatever they want, but if they choose a direction that somehow fails to represent what's MDN is about, it's not really whining, rather hoping that's still a remote possibility to change such decision.
Since the main developer that should be interested in working, and hearing, in the open, is purposely ignoring this thread, I guess we can close this to avoid further irrespecutful comments 👋

Since the main developer that should be interested in working, and hearing, in the open, is purposely ignoring this thread

This is the saddest part of all of this.
Again i'll take some words from Mozilla, this time from Mitchell Baker in an email asking for support:

People are asking, "The internet is broken, what can I do?" An important part of the answer is, build a relationship with Mozilla.
Make it as deep as you want. Sign up, ask your friends and family to sign up, donate. You should have a relationship with Mozilla. That’s where you can improve the internet as you improve your own experience on the internet.
We must demand better of the internet. And we must grow the number of people joining together with us to demand better of the internet.

So here i'm, trying to make a relationship with Mozilla and help, in my understanding, create a better web, free of non standard stuff. Just to be ignored.

This entire thread is hilarious. If you're THAT mad about what framework they use to make their website, you can always just use w3schools instead.

Can we please close this thread to avoid previous kind of irrelevant comments that would pointlessly notify everyone?
Thank you.

Its Friday afternoon. I'm going to try to bring some closure to this thread without, I hope, stirring up more controversy. And then I'm going to try to put this behind me and get back to work next week.

This mdn/sprints repo is the MDN's team alternative to Trello and similar tools. As its name suggests, it is how we plan our work. Instead of creating cards on a private Trello board to track our user stories, we create issues in this repo. So we're working in the open, and anyone who wants to look over our shoulders can, but this repo is not really a place where we typically engage in debate or discussion about the user stories.

I tried to mute email notifications for this github thread and I also said that I didn't promise to read all of the comments.  As it turns out the joke was on me: I was never really able to mute notifications because I kept getting tagged by name and github started sending emails again. At this point, I think I have read more than 80% of the comments here. I have been tempted to respond to some of your comments individually, but fear of creating more controversy has stopped me. Please do try to see this from my perspective:  imagine yourself at work, at the start of a new sprint, and out of the blue someone on Twitter links to one of the Trello cards assigned to you, and then dozens of people start offering you unsolicited opinions on how to complete your task. What do you do? Do you spend a day responding to the comments, or do you try to ignore the noise and carry on with your duly assigned work?

The decision to use React was properly made by the core contributors to the mozilla/Kuma repo. Currently that set of core contributors is the set of Mozilla employees who are paid to work on it. We do have occasional volunteer contributions, but we do not really have an active volunteer community around the Kuma server that drives MDN. (You all may not believe this, but I actually believe that using React for our frontend code may lower the barrier to entry for this project and increase our ability to attract volunteers.) My point is that the React decision was appropriately made by the engineers who are actively working on the project. It was never our goal to achieve consensus on this decision, nor would any kind of consensus be possible. I recognize that many of you are very passionate about web standards and about MDN, and I'm honored to be part of a project that inspires such passion.  But your passion is not the same as working daily on a project (and having your annual review tied to the success or failure of the project!)

The decision to use React had not been communicated yet outside of the MDN team. We were not hiding it; we just hadn't attempted to announce it in any way yet. This is because we don't have anything to show yet. My work this month is to try to figure out how we are going to use React. This particular user story that we're all commenting on happens to be about the site header and menus, but only because I'm using that as a non-trivial proof-of-concept. The work this month is intended to remain on our staging servers and not be deployed to production. So while you may have been taken by surprise by this decision it is not because we were trying to be sneaky about it: there's just nothing there yet.

I used the decision about React as a test case for a new ADR (Architectural Decision Record) process for recording our decisions and the reasoning behind them.  We're trying the process out and doing it in the open by default. It may nor may not work and we may or may not get any more ADRs checked in to the mdn/mdn repo. I'm hoping to make it a really lightweight process to encourage my teammates to make records of their decisions. My hope is that our ADRs will be a publicly readable record of our decisions. But if we find that we have to word them really carefully to avoid public controversy, then I expect that they'll turn out to be more trouble than they are worth and we'll drop them.  When I wrote the ADR about React, I apparently misread the shadow dom v1 adoption stats on caniuse.com and stated that browser support for web components was lower than it actually is. I've corrected this in a superseding ADR. (It is still a pull request, but should land in the mdn/mdn repo soon.) The decision to use React still stands, but the section about web components is updated.

The majority of the commenters on this thread seem to dislike React. For the record, though, let's be clear that React is open-source and that React is a tool for producing websites that are built from the web standards of HTML, CSS and JavaScript. Yes, there are intermediate steps (jsx) that are not web standards, but the end product–the MDN website–is still based on standards. Its not like we're using Flash for our drop-down menus and an ActiveX plugin to display documentation in MS Word format! I'm guessing that many of you disagree, but I feel that a developers choice of tools–including frameworks–is a matter of taste. You may love vscode, but you're never going to get me to give up my emacs. And I may love React, but I'm not going to try to tell you that you should use it on your projects. Please don't judge me and my team on the tools we use, but on the quality of the websites we produce.

I love web components. I had the opportunity to use them just a little bit as the FirefoxOS project was wrapping up years ago. And I look forward to using them again some day. But: I spent 18 months using React at Khan Academy and found it to be a huge productivity boost. There is a reason that so many developers use React: it, and the mature ecosystem of tools around it, works really, really well for rapid frontend development. This may sound harsh, but if you haven't used React on a midsize (like MDN) or larger website, I don't believe that you are qualified to judge our decision.  And if you haven't worked as a frontend developer in an environment where you've got product managers and user researchers and marketing teams asking you weekly to add features and A/B tests and banners to the website, then you're also not qualified to judge this decision, either.  As I've said elsewhere in this thread, we're expecting to be asked to do a lot of frontend work on MDN in 2019, and it is our judgement that using React will maximize our chances of being able to complete that work. This is in part because it will make our core team (of 2 FE engineers) most effective. But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it. We haven't released a 2019 roadmap, and I can't talk about our plans right now in any more detail than that we expect to be doing a lot of frontend work. And so this also means that if you're not part of the core MDN team today you don't have enough context to understand our decision.

I hear your concerns about code bloat, tag soup and accessibility. Please remember that we are experienced professionals and we understand how to avoid those problems. (And as Dan Abramov pointed out earlier in the thread, there is a lot of FUD that blames React for those problems, when the fault really lies in lazy development practices.) We're not going to adopt React and then deliver web pages that are big and slow to load.  I've also heard a number of you pointing out that UX trumps DX. I agree. But we've got a lot of UX to deliver this year,  and we need all the DX help we can get from our tools. If React is the framework that is going to allow us to achieve our goals, then React is what we're going to use.  And I've heard a number of you mourning the demise of view source. (I kind of agree, but I don't have any data to know whether anyone actually learns web development that way anymore, or if we're all just kind of nostalgic.) If we end up doing significant server side rendering of our React components, then much of the HTML source will still be viewable via view source. But even without SSR, React produces perfectly standard HTML and CSS, that is viewable (much more usefully than a static view source view) through developer tools.

Many of you have said that a website about web standards really ought to practice what it preaches and should use those web standards itself. I've already rejected the claim that there is something immoral or impure about React–it is a developer tool for producing websites based on standard HTML, CSS and JavaScript. But I get it: it would be really cool if the MDN website could push the envelope and be a public demonstration of web components (and other cutting edge technologies like service workers, for example).  And if this was a personal project without a tight schedule, or if Mozilla was able to dedicate more paid employees to the job, then maybe that would be possible. I would honestly like to do that. But MDN's mission is to document web standards, not to demonstrate or dogfood them. Like any organization we've got a hierarchy and a planning process. We've got OKRs ("Objectives and Key Results") that guide our work for the year. And "Lead by example by adopting web components" is simply not one of our key results this year. If I thought it was the best way to achieve the results that are on our list, I would do it in a heartbeat.

Fundamentally, I'm asking you all to trust us. We're hoping to do great things this year with MDN, and I think that the vast majority of our users will love what we do. Thank you for reading this far, and thank you for your passion about web standards and MDN.

Respectfully,
David Flanagan

@davidflanagan ( just to be sure you'll read this 😄 ) I won't go answering point after point 'cause you have the rights to spend a peaceful weekend, and put this week behind, but I still think the message this will send will have bad repercussion for the Web development in the long term.
I've worked in 20 years from small, to medium and big projects (including FB and Twitter), and with the plethora of tools available these days, I don't buy this productivity boost you are mentioning, simply because if you need indirections to represent the Web after all, you're putting an extra layer on top, not one less.
Regardless, I do agree tools, including programming languages, are a matter of personal taste, selling these as "the only way to scale and develop medium size projects" should be kept underlined as highly subjective too.
In any case, I do really appreciate your time to properly address most comments and better describe what is this repository a part (I work in the Open Daily too, I can't imagine handling threads like this while we make decisions for our product specs) so, in few words, thank you.

A lot of ppl suggesting web components are missing the point, let devs choose the tech they want to keep them engaged and productive specially when web components are extremely dreadful to work with, at the end of the day the tech doesn't matter, what matters is the end result, and if the team is happy and have a choice of the tech stack, they should write it in whatever they like.

let devs choose the tech they want to keep them engaged and productive

Some MDN devs are still learning React (this info was deleted in OP), so being productive is not certain

web components are extremely dreadful to work with

This is opinion, many find React to be dreadful and think web components are " the tech they want to keep them engaged and productive"

the tech doesn't matter

This is debatable, see above comments, but will not counter argument (again)

what matters is the end result

Very true. Given the nature of project (and defined objectives) React seems not appropriate, with some caveats waiting for the devs. Let's see what we will get in a few months

@blikblum An engaged developer is always more productive and a motivated team put more effort and hours into the project while having more fun. The fact MDM guys are still learning react is also what driving the whole thing, to use opportunities to learn new tech in practical environment.
I work for google and 3 month's ago for the first time in years I was given an opportunity to select tech stack for a pilot project, never seen the team so driven and excited before, the tech stack was GO+React.
btw just FYI the way opinions work is that everything I say is my opinion, no need to select one particular statement :)

@AlekzZz no problems with React or Angular or Backbone or nothing at all, specially for projects starting from the ground with few upfront constraints.
In my opinion, with the declared objectives (feel free to read above), the number of challenges integrating React will be no negligent. But leading with those challenges is part of learning process.
As you said,  what matters is the end product, so let's see in a few months were this will end.

Wait... is this whole conversation about just making the sub-nav in the header open on click instead of hover? Seems like a couple of lines(literally just toggle some class names) of vanilla js would do that easily. Why would you bring in a any framework to do that? I feel like I've missed something.

@davidflanagan One thing you'll find rewriting the header is there is going to be some tricky logic dealing with React synthetic click/keyboard events and actual DOM events clashing a bit when you click on a React drop down element and a non react element.  Happy to help if you get to that point.

Wow never thought about the learning perspective and letting people
contribute, whether paid or volunteer, to also build in a way to support
their goals.
Important point to consider.
On Thu, Feb 21, 2019, 1:25 PM afr114<EMAIL_ADDRESS>wrote:

@davidflanagan https://github.com/davidflanagan One thing you'll find
rewriting the header is there is going to be some tricky logic dealing with
React synthetic click/keyboard events and actual DOM events clashing a bit
when you click on a React drop down element and a non react element. Happy
to help if you get to that point.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mdn/sprints/issues/967#issuecomment-466110591, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKC-pvhTHJwO6vGGktoI19ZJO6LdnQqiks5vPuSQgaJpZM4amRE9
.

Random advice from a random dev 😎 : I've always struggled with chosing the right technology. But then sometimes you just have to go in and do the job.
But if you are consistent, you can just remove the fear of bad choices knowing you have something like jscodeshift (sorry haters, it's another facebook library) and change everything with peace of mind. Edit the transform, run it, check results, git checkout, rinse & repeat until happy.
Just go with whatever you want, be consistent, and you can, if you want it, just shift everything if you aren't happy with the result. Go from mocha to jest, jest to mocha, react to mithril, mithril to snabbdom, react to hyperhtml, rxjs to mostjs, jquery.ajax to superagent, pattern to pattern.
If there's a pattern, you can find & transform it. Go nuts :shipit:
This concept of coding editing code for me changed my life as a developer. I truly hope it becomes available, in one form or another, in all available languages.

This is working on the staging server, which is as far as we're planning on taking it for now, so I'm closing the issue.


WSL repo for Ubuntu doesn't have a Release file

This page:
https://docs.microsoft.com/en-us/windows-server/administration/linux-package-repository-for-microsoft-software
gives instructions for configuring the software repositories for Ubuntu 20.04 (I ran these as root, so sudo is not required):

curl -sSL https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
apt-add-repository https://packages.microsoft.com/ubuntu/20.04/prod
apt-get update

AFAIK I followed the instructions correctly, but find two problems:

I get a TLS error (but apt continues past this error)
a Release file could not be found, and apt exits

The output from "apt update" (run as root) is shown below.
Is the Microsoft repo complete (i.e. it is configured correctly with the required Release file), or is the problem on my local machine?

apt update
Ign:1 https://wsl-translinux.arkane-systems.net/apt  InRelease
Ign:2 https://packages.microsoft.com/ubuntu/20.04/prod focal InRelease
Err:3 https://packages.microsoft.com/ubuntu/20.04/prod focal Release
Could not handshake: The TLS connection was non-properly terminated. [IP:  80]
...
Reading package lists... Done
E: The repository 'https://packages.microsoft.com/ubuntu/20.04/prod focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 25943cc5-9927-5ca7-b9db-4c1d398726c5
Version Independent ID: ae5bf48b-26cf-b5c8-22c8-68fa9a70258f
Content: Linux Software Repository for Microsoft Products
Content Source: WindowsServerDocs/administration/Linux-Package-Repository-for-Microsoft-Software.md
Product: windows-server
Technology: administration
GitHub Login: @victorcheng7
Microsoft Alias: vichen

Could it be that running the commands as root is treated differently compared to when the sudo commands are used? I seem to recall seeing a couple of repositories where the instructions clearly underline or recommend using sudo, advocating against the root user to perform repo update commands on their local clones. (I am not an expert, so I could easily be mistaken regarding this specific issue.)

Nah, there should not be any difference.
It's always recommended using sudo instead of actually becoming the root user since we should focus on performing as few tasks as we can with elevated privileges.
Besides that, sudo can be configured so that a user only can perform certain administrative tasks, e.g. adding and updating apt repositories or restarting a service, among other things.

I was running as root as it was easier to get through our proxy, but I got sudo working.
"sudo apt update" works as expected.
Thanks for the comments.


Minor fixes

An exception created but not thrown

I agree that the Exception throwing is a bug that needs to be fixed.
As for the whitespace change. You add a blank line at the top of the class whilst removing one from the end.


build(formatting): add markdownlint and .editorconfig

Format all files.

Coverage remained the same at 100.0% when pulling 3f95404bce7ee0237c59fdf71a09a481aad9f597 on add-markdownlint into 806e766698a8e75f389f09f316966e2c23630890 on main.

Coverage remained the same at 100.0% when pulling 3f95404bce7ee0237c59fdf71a09a481aad9f597 on add-markdownlint into 806e766698a8e75f389f09f316966e2c23630890 on main.

:tada: This PR is included in version 1.2.11 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


[bug] function too large & AxiosError: Network Error

Search before asking

[X] I had searched in the issues and found no similar issues.

Environment
https://laf.dev
What happened
When the content of a function is too large, an error will be reported when executed

How to reproduce
Function Content Big Error，AxiosError: Network Error
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Fixed.


Re-authenticate when refresh token expires

The CF CLI manages 2 auth tokens (it stores them in ~/.cf/config.json):

An Access Token with a 2-hour lifespan. When this token expires mid-session, the CF CLI requests a new one from the CF API using:...
A Refresh Token with a 2-week lifespan. When this token expires, the CF CLI requires re-authentication (from what I understand)

Our extension currently only performs an authentication request (i.e. retrieval of a new refresh token) when connecting to a new "Cloud Foundry Instance" for the first time. This means that we can expect users of our extension to encounter issues after 2 weeks of using the same "Cloud connection" if they don't manually re-login (and nothing about our extension makes that clear at the moment).

Possible solution:

After authenticating for the first time, read the CF CLI config file & record the value of the refresh token

(unfortunately, there might not be a better way to read the refresh token; there's no CF CLI method that will return the value, and the refresh token is obfuscated when printing all http info using cf login -v)

In the GetOAuthToken method, before checking the access token's expiration time, check the refresh token's expiration time

If the refresh token hasn't yet expired, proceed to check access token validity etc.

If the refresh token has expired, prompt re-authentication (this might require a bit of refactor to prevent CfCliService from invoking CloudFoundryService methods)

We could guess where the CF CLI config file lives (~/.cf is the default, so that'd be a decent guess), but it'll be safer to read the refresh token from config.json file once this VS extension has a dedicated location for that file (see #89).

CF CLI METHODS

valid AT, valid RT => request succeeds
invalid AT, valid RT => CF CLI uses RT to get new AT & retries request
valid AT, invalid RT => request succeeds
invalid AT, invalid RT => CF CLI tries to use RT to get a new AT & fails with exit code 1.

If StdErr == "The token expired, was revoked, or the token ID is incorrect. Please log back in to re-authenticate.", prompt login
Else, proceed with default error (issue is not an invalid RT)

CF API CLIENT METHODS:

valid AT, valid RT => request succeeds
invalid AT, valid RT => method retried in CloudFoundryService with fresh AT
valid AT, invalid RT => request succeeds
invalid AT, invalid RT => method retried once in CloudFoundryService, fails again. After failed retry, read RT from CF CLI config file & check for validity.

If RT is expired, prompt login
Else, throw default error (this assumes that the RT is still valid, which could be an issue if the RT became invalid before the end of its precribed lifetime)

Sample login window title:
Your session has expired, please log back in to re-authenticate.

Do we have to worry about canceling tasks when the refresh token expires in a scenario like this?

refresh poller initiates 10 refresh tasks: "taskA" - "taskJ"
taskA completes successfully
taskB completes successfully
refresh token expires (but access token is still valid)
taskC completes successfully
taskD completes successfully
taskE completes successfully
access token expires
taskF fails the first time due to an expired access token & tries to get a fresh access token using the (expired) refresh token
some (not yet implemented) process recognizes an expired refresh token & prompts the user to log back in for re-authentication
TaskG fails the first time due to an expired access token, ... then what? Re-prompts the user to log back in for re-authentication due to an expired refresh token?
TaskH fails the first time due to an expired access token, ... then what? Re-prompts the user to log back in for re-authentication due to an expired refresh token?
TaskI fails the first time due to an expired access token, ... then what? Re-prompts the user to log back in for re-authentication due to an expired refresh token?
TaskJ fails the first time due to an expired access token, ... then what? Re-prompts the user to log back in for re-authentication due to an expired refresh token?
... those are a lot of unnecessary re-prompts ...

New idea:
Let's keep track of whether or not a CloudFoundryInstance shown in the CloudExplorer window is authenticated & have the refresh poller check this value before it starts each round of background refreshes.
When first logging in to a CF instance, mark it as authenticated.
Whenever a CF operation needs to get a fresh access token but the refresh token is expired, mark that CF instance as NOT authenticated.
Whenever the refresh poller discovers that a CF instance is not authenticated (specifically, when it tries to run CloudExplorerViewModel.RefreshAllItems()), display some sort of notification INSIDE the Cloud Explorer tool window that indicates re-authentication is required.

CfCliService.GetOAuthToken is now throwing an InvalidRefreshTokenException whenever it gets this response as StdErr from the CmdProcessService: "The token expired, was revoked, or the token ID is incorrect. Please log back in to re-authenticate."
All 6 CloudFoundryService methods which use CfCliService.GetOAuthToken (get orgs/spaces/apps + stop/start/delete app) are now catching any InvalidRefreshTokenExceptions & responding by returning a DetailedResult with FailureType == InvalidRefreshToken.
I've tested this in the debugger & seen it work for GetOrgsAsync! I'm assuming the same is true for the other 5 methods, since the code is identical.
TODO:

have the cloud explorer view model monitor the Authenticated status of each CloudFoundryInstance & take appropriate action when it notices that one has become unauthenticated.
fix refresh flow so that no refresh attempt is made when the CF in question is marked as not authenticated.
make sure no modals (error windows) pop up because of an invalid refresh token during the background refresh task.
investigate tree view behavior when tokens are both invalid during a refresh -- should the methods for getting orgs/spaces/apps return empty lists (e.g. report "no orgs")? Or should they return whatever was in place before the refresh to simulate a no-op (i.e. leave the tree view visually unchanged)?

TODO:

Change all predicates in CloudExplorerViewModel to return false if not Authenticated

De-authentication via automatic refresh behavior has been verified for these methods:

[ ] CfInstanceViewModel.RefreshChildren
[ ] OrgViewModel.RefreshChildren
[x] SpaceViewModel.RefreshChildren

Just pushed a series of commits to refresh-token-expiration-#37 (kept previous unpolished progress in a separate branch on the remote: refresh-token-expiration-#37-old). These changes make it so that any "active" attempt to get orgs/spaces/apps which fails because of an invalid refresh token will display an error pop-up explaining the issue & set CloudExplorerViewModel.AuthenticationRequired to true. Any "passive" attempts to fetch children for cfs/orgs/spaces will not display any pop-ups but will set the AuthenticationRequired flag the same way. Whenever CloudExplorerViewModel.AuthenticationRequired is set to true, the window displays a button (next to the refresh button for now) which, when clicked, will remove the topmost CF (there should only ever be 1) & display the login window again. A successful login will reset AuthenticationRequired to false, clearing the auth warning button.
TODO:

remove unused prop on CloudFoundryInstance: Authenticated (no longer need this value as it's kept track of on the CloudExplorerViewModel now that I've replaced the auth-polling system with an auth feedback mechanism from each TreeViewItemViewModel back to the CloudExplorerViewModel).
add support for other methods that may require re-authentication, like app deployment or getting app logs

note: some of these may not use CfCliService.GetOAuthToken (e.g. if they happen via the CF CLI entirely and not the CfApiClient), so we'll need another mechanism for detecting when the refresh token is invalid (maybe we can scan the StdErr for the same failure message?)

optionally: condense all logic having to do with verifying auth stuff into a single place?

Here are the CF CLI methods we're currently using:

GetOAuthToken (6 usages in CloudFoundryService)
TargetApi (1 usage in CloudFoundryService.ConnectToCFAsync)
AuthenticateAsync (1 usage in CloudFoundryService.ConnectToCFAsync)
PushAppAsync (1 usage in CloudFoundryService.DeployAppAsync)
GetApiVersion (1 usage in CloudFoundryService.MatchCliVersionToApiVersion)
GetRecentAppLogs (1 usage in CloudFoundryService.GetRecentLogs)
ClearCachedAccessToken (6 usages in CloudFoundryService)

ExecuteCfCliCommand is only in use within CfCliService itself; this method is probably safe to make private.
All other CF CLI methods are tested but not in use (GetOrgsAsync, GetSpacesAsync, TargetOrg, TargetSpace, GetAppsAsync, StopAppByNameAsync, StartAppByNameAsync, DeleteAppByNameAsync)
Fore each of those 7 used methods, here's a table showing their underlying CF CLI methods + whether or not those methods fail due to an invalid refresh token:

CF CLI Method
Token-dependent
Token-independent

1. oauth-token
✅

2. api

✅

3. auth

4. push

5. api

6. logs

7. N/A (doesn't use CF CLI)

The comment above shows that oauth-token, push, and logs are the only 3 CF CLI methods in use by our extension that could encounter an error due to an invalid refresh token.

oauth-token is now covered (as of the changes pushed up to the refresh-token-expiration-#37 branch last night).
push needs protection. Since this is an "active" operation within our extension, an error notification should pop up if a deployment can't be completed due to an invalid refresh token.
logs needs protection. Since this is an "active" operation within our extension, an error notification should pop up if a deployment can't be completed due to an invalid refresh token.

Turns out we can't completely ignore the other methods in CfCliService (GetOrgsAsync, GetSpacesAsync, TargetOrg, TargetSpace, GetAppsAsync, StopAppByNameAsync, StartAppByNameAsync, and DeleteAppByNameAsync) because some are still in use within "used" methods on CfCliService.
E.g. PushAppAsync uses TargetOrg & TargetOrg is at risk of encountering an error due to an invalid refresh token.
I've added extra rows to the table from above to capture the importance of guarding against invalid refresh token errors for those remaining methods:

Deployment can now recover from an invalid refresh token:
https://images.zenhubusercontent.com/327998348/4ec02733-daa0-4727-b258-0365ca367ca1/deploywhilenotauthenticated.mp4

Getting recent app logs can now recover from an invalid refresh token:
https://images.zenhubusercontent.com/327998348/96cd0c9a-cda7-4b4b-a93b-4fcf94f5ecfc/getrecentapplogswhilenotauthenticated.mp4


Added support for controlling the op_type when indexing

In order to write to data streams we'll need to set the
op_type to create the default is index
In order to don't serialize null values for the batch action and to not depend
on custom serialization setting we're using LowLevelRequestResponseSerializer.Instance
for serialization of the action.
We won't throw exception when setting the TypeName to null since:

This is deprecated in v7
Won't work in v8

What issue does this PR address?

#355 It's possible to set the op_type to create by setting BatchAction to ElasticOpType.Create
#345 It's possible to set TypeName to null to remove it from the payload being sent to Elastic.

Does this PR introduce a breaking change?
I don't think we have introduced an breaking change but we'll need to review the following changes to make sure they're not breaking.

The custom serializer for the action has been replaced by a specific one, it's not impossible that someone has been intercepting this call for adding custom elements when logging.
https://github.com/serilog/serilog-sinks-elasticsearch/pull/356/files#diff-15ec7bbc1a4d48125fae012ffb1896acR191

Earlier and exception was thrown when trying to set the TypeName to null it's unlikely that someone has relied on this exception. https://github.com/serilog/serilog-sinks-elasticsearch/pull/356/files#diff-cb61ceb2dfe8091b1abe76e3c275d6d0L77

Please check if the PR fulfills these requirements

[x] The commit follows our guidelines
[x] Unit Tests for the changes have been added (for bug fixes / features)

Other information:

Thanks for this PR. Looks good. I agree with your points, the exception type does not look like an issue, the other one might be an issue. But that we can highlight in the changes.md and readme.md.

@mivano currently there's an issue with the error handling since when we're setting the OpType to create it won't work, since it's looking for index. Also there an open PR #284 trying to address another issue with error.
The question is would we like to stay with the DynamicResponse or are we open to de-serialize the response to DTO:s instead?

Another thing that crossed my mind; the durable part also sends data to ES in a similar manner, but using different code constructs. Most likely the same issue will apply here. For some while now I feel less comfortable with this durable part. It is a large part of the code base with a lot of duplication. And that last part makes introducing these changes more difficult. Besides, the durable functionality is not as stable as it should be and there might be better solutions if you want similar behaviour.
What is your take on this? Worthwhile to apply the same thing to the durable part, exclude it explicitly or something else?

Another thing that crossed my mind; the durable part also sends data to ES in a similar manner, but using different code constructs. Most likely the same issue will apply here. For some while now I feel less comfortable with this durable part. It is a large part of the code base with a lot of duplication. And that last part makes introducing these changes more difficult. Besides, the durable functionality is not as stable as it should be and there might be better solutions if you want similar behaviour.
What is your take on this? Worthwhile to apply the same thing to the durable part, exclude it explicitly or something else?

I did a quick fix for the durable part and there are 2 places that needs to be fixed, so I'll fix that as well.
I'm not sure what we should do about the duplicated implementations, in the best of world we should isolate the durable part to a separate lib or at least namespace if possible? Are there any other durable sinks with the same needs?

A totally separate discussion of course from this PR, but I would be inclined to remove it out of this sink and offer functionality in a different way. Preferable using a higher abstraction, so you can specify it on the serilog sinks level instead. This original implementation came from the Seq one (https://github.com/serilog/serilog-sinks-seq/tree/dev/src/Serilog.Sinks.Seq/Sinks/Seq/Durable) so there are more sinks with a similar feature. Problem is that I do not know how many users are actually depending on this durable feature. So it would be a real breaking change with or without another solution.

Merging it into dev so we have a prerelease package.


Vg-metric fix on run command

VG-metric was being run with illegal --scheme  option, fixed

Confirmed: https://github.com/blueboxgroup/ursula-monitoring/blob/master/sensu/plugins/metrics-volgroup.sh#L16


crash

app crash reason applovin ads package

Hey there - AppLovin just released an official plugin. Please feel free to check it out here: (docs, repo).
Thank you @ioridev for developing this stop-gap solution, we really appreciate it.


Final screenshots/ embeds not shown in reports

I'm experiencing an issue where items embedded in the scenario in a method annotated with @After don't appear in the cluecumber reports. I believe that they are correctly being embedded because they appear in the default Cucumber html output.

Have you checked that the after hooks are displayed in the report by clicking on the upper right button in the report?
You can also display after hooks per default using <expandBeforeAfterHooks>true</expandBeforeAfterHooks>

@GregJohnStewart did this solve it?

Apologies, it has been busy. Yes, it did, Thanks!


"conflict with the backend dependencies" with pip 19

[x] I am on the latest Poetry version.

[x] I have searched the issues of this repo and believe that this is not a duplicate.

[x] If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

OS version and name: Linux, RHEL7.5

Poetry version: 0.12.11

Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/danmur/fe1b9685b8f6fa87fad4764be892f9f9

$ ~/pythons/poetry2/bin/poetry install -vvvv
Using virtualenv: /home/daniel.j.murray/git/testapp/.venv
Installing dependencies from lock file

Nothing to install or update

  - Skipping scandir (1.9.0) Already installed
  - Skipping six (1.12.0) Already installed
  - Skipping atomicwrites (1.2.1) Already installed
  - Skipping attrs (18.2.0) Already installed
  - Skipping certifi (2018.11.29) Already installed
  - Skipping chardet (3.0.4) Already installed
  - Skipping colorama (0.4.1) Not needed for the current environment
  - Skipping funcsigs (1.0.2) Already installed
  - Skipping idna (2.5) Already installed
  - Skipping more-itertools (5.0.0) Already installed
  - Skipping pathlib2 (2.3.3) Already installed
  - Skipping pluggy (0.8.1) Already installed
  - Skipping py (1.7.0) Already installed
  - Skipping urllib3 (1.22) Already installed
  - Skipping pytest (3.10.1) Already installed
  - Skipping requests (2.18.3) Already installed
  - Installing testapp (0.1.0)

[EnvCommandError]
Command ['/home/daniel.j.murray/git/testapp/.venv/bin/pip', 'install', '-e', '/home/daniel.j.murray/git/testapp', '--no-deps'] errored with the followi
ng output:
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A fu
ture version of pip will drop support for Python 2.7.
Looking in indexes: xxx
Obtaining file:///home/daniel.j.murray/git/testapp
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
Some build dependencies for file:///home/daniel.j.murray/git/testapp conflict with the backend dependencies: requests==2.21.0 is incompatible with requests
==2.18.3.

Exception trace:
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/cleo/application.py in run() at line 94
   status_code = self.do_run(input_, output_)
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/poetry/console/application.py in do_run() at line 88
   return super(Application, self).do_run(i, o)
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/cleo/application.py in do_run() at line 197
   status_code = command.run(input_, output_)
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/poetry/console/commands/command.py in run() at line 77
   return super(BaseCommand, self).run(i, o)
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/cleo/commands/base_command.py in run() at line 146
   status_code = self.execute(input_, output_)
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/cleo/commands/command.py in execute() at line 107
   return self.handle()
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/poetry/console/commands/install.py in handle() at line 89
   self.env.run("pip", "install", "-e", str(setup.parent), "--no-deps")
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/poetry/utils/env.py in run() at line 492
   return super(VirtualEnv, self).run(bin, *args, **kwargs)
 /home/daniel.j.murray/pythons/poetry2/lib/python2.7/site-packages/poetry/utils/env.py in run() at line 354
   raise EnvCommandError(e)

install [--no-dev] [--dry-run] [-E|--extras EXTRAS] [--develop DEVELOP]

The issue seems to be having requirements on poetry dependencies with this new version of pip. I have a dependency on requests 2.18.3, which I imagine poetry does too but for a different version, and pip is trying to treat this as a conflict here:
https://github.com/pypa/pip/blob/8ff8e1fa9e9c70b1fa285a8c02223e92a53d05ef/src/pip/_internal/operations/prepare.py#L151
Commenting out the [build-system] bit in pyproject.toml works around it.
I am not sure if this is a poetry issue or a pip issue; if it seems more like a pip issue let me know and I'll file it there :)

Downgrading pip to 18.1 also seems to be a valid workaround.

Commenting the build-system section out worked for me, but downgrading to 18.1 did not...

I've filed a pip issue here: https://github.com/pypa/pip/issues/6314
Hopefully between the projects we'll get this sorted out, but @sdispater has been awfully quiet of late :'(

@danmur - would you be able to try requests = "^2.18.3" in your project as an alternative workaround?

@sdispater - so, it looks like this is a poetry bug that is going to make poetry unusable with pip 19 when the "fix" for pypa/pip#6314 lands.
The quickest fix for poetry would be to move pyproject.toml to pyproject.toml.not before doing the pip install -e with the synthesised setup.py and move it back when it deletes the setup.py.
I'm curious: why does poetry need to do the pip install -e with the fake setup.py in the first place?

I have the same problem trying to install orator from source... The problem can be bypassed if I downgrade pip to 18.1 but this is not a solution...
pip install --upgrade pip==18.1

I think this issue is a priority, it will make poetry unusable in some cases. Is @sdispater the only maintainer?

@psincraian - yes, I'm afraid @sdispater is currently the only maintainer...

@sdispater - this issue may be come fairly critical at any time, and probably some time soon, see https://github.com/pypa/pip/issues/6314.

Hi @sdispater
This is really critical! The easiest way to reproduce this is to run with pip 19:
poetry new foobar
poetry add cleo  # Actual version 0.7.X
poetry install

Since poetry itself is sticked to cleo 0.6.X, any packages willing to use cleo 0.7.X will result in raising an exception

I'm still experiencing this behavior even when using pip 18.1 in CircleCI.  Has there been any progress made on this and if not, how can I help?

I thought #697 is a thread related to this.


Transpose confusion matrix to fix precision and recall

Following up on discussion in #29, instead of changing the axis each metric is calculated on, simply transpose the confusion matrix to fix precision and recall calcs. This does change the value reported by Frequency_Weighted_Intersection_over_Union() also, but no other metrics.
I think FWIoU on the transposed confusion matrix is correct though as the frequency is calculated column-wise where each column is now the label, not the prediction.

This looks good. Now the CM and all the metrics derived from it should be correct. Thank you!


feature request: include metric name in metric check alerts

We have a number of instances of our app reporting metrics to graphite and they all follow the same naming scheme.
We have configured a check for a metric named something like:
instances.*.lag
And we do get alerts when the lag of any instance goes up, but we'd like to know which one it was.
Is there a way to do this or could you please add it?
Thank you

I believe this is the current behaviour. I used aliasByName so that the metric is aliased to the instance name, and that does pop up in HipChat:
Service MyService reporting ERROR status: https://cabot.example.com/service/1/. Checks failing:  cluster load  (wrk01: 0.13 > 0.0, wrk02: 0.16 > 0.0, wrk03: 0.12 > 0.0) @jeanfred


update definition of country

It needs to be clear that the 'country' is for the location of the data center, not the geographic location of the dataset.

Noting that some WMO Members are not countries, is it better to name this level "member" or something else other than "country"?

It needs to be clear that the 'country' is for the location of the data center, not the geographic location of the dataset.

@amilan17 yes, we can articulate the "data centre" or "issuing centre" as part of the documentation (related #46)

Noting that some WMO Members are not countries, is it better to name this level "member" or something else other than "country"?

@yhe-wmo at the country level, we support WMO RAs (i.e. RAI: xxa, RAII: xxb, etc.) as well as global centres (xxg), using the "xx*" notation in alignment with ISO 3166 alpha3.  Thus any member (at the centre-id level), would be able to associate with a country, WMO RA, or global entity.

Noting that some WMO Members are not countries, is it better to name this level "member" or something else other than "country"?

@yhe-wmo pointed out to me that Hong Kong is a Member but should not be referred to as a country.

superseded by #58