devographics / state-of-js-graphql-results-api Goto Github PK
View Code? Open in Web Editor NEWState of JS GraphQL API
State of JS GraphQL API
This is related to #78
Unfortunately, the "Leave an issue" link on the JS survey does not actually work now.
So I think we need to go back to interpolation delimiters (without "$") in Vulcan.js style, and for survey results on Gatsby define custom delimiters in the Lodash template in translator.js file, this way interpolation will work the same for both frameworks.
cc @SachaG
Add it-IT missing translations to accounts.yml file.
There is a typo in one of the results.yml
file's keys.
key: award.most_write_ins_award.descriptiona
Shouldn't it be description
?
I wanted to start translating it, so following our fellow japanese friends, i'll follow their style to organize it!
As far as I checked, some files already have partial translations.
If you want to contribute Spanish translation, please let us know here!
This thread will contain all info related to translating the State of CSS and State of JS surveys going forward.
The YAML files to translate live in this current repo, which contains our API:
IMPORTANT: also check that there aren't any existing PRs for the language you want to translate first!
Every translator will be credited on any site that makes use of the translations, starting with the survey-taking app. You can add your name here if it's not already there.
You can get extra data such as the completion percentage for a locale or the untranslated strings via our API, available at:
Here is a sample query:
query GetLocaleData {
locale(localeId: "ru-RU") {
completion
totalCount
translatedCount
translators
untranslatedKeys
}
}
These strings are related to the app that you use to fill out the actual survey.
surveys.yml
accounts.yml
state_of_js_2020_survey.yml
These strings only appear in the static site that displays the survey results and stats.
results.yml
state_of_css_2020.yml
state_of_js_2020.yml
These strings appear in both.
common.yml
state_of_css.yml
state_of_js.yml
homepage.yml
It's recommended you join the translation team for the language you want to translate.
You may also want to take a look at previous year's translations if that helps:
There should be a separate, anonymized development database for people who want to work on the API.
Hello.
thank you for StateOfJS.
every year, I see the your survey. this is very helpful to me.
Actually, I want to translate to Korean.
So How can I help you do that?
just can I PR ?
Currently, you can search for e.g. the age range distribution of survey respondents and get data that looks like this:
{
"data": {
"survey": {
"demographics": {
"age": {
"year": {
"buckets": [
{
"id": "range_less_than_10",
"count": 3,
"percentage": 0
},
{
"id": "range_10_18",
"count": 95,
"percentage": 1.5
},
{
"id": "range_18_24",
"count": 678,
"percentage": 10.4
},
{
"id": "range_25_34",
"count": 3289,
"percentage": 50.6
},
{
"id": "range_35_44",
"count": 1901,
"percentage": 29.2
},
{
"id": "range_45_54",
"count": 433,
"percentage": 6.7
},
{
"id": "range_55_64",
"count": 83,
"percentage": 1.3
},
{
"id": "range_more_than_65",
"count": 18,
"percentage": 0.3
}
]
}
}
}
}
}
}
You can also filter this by e.g. gender to limit the results to women.
But I would like to add an option to group the results by gender (or any other demographic "facet" – not sure if that's the proper term by the way?). So the resulting data would look something like this:
{
"data": {
"survey": {
"demographics": {
"age": {
"year": {
"facets": [
{
"type": "gender", // could be "country", "age", "salary", etc.
"id": "female", // the value we're currently grouping by
"buckets": [
{
"id": "range_less_than_10",
"count": 3,
"percentage": 0
},
{
"id": "range_10_18",
"count": 95,
"percentage": 1.5
},
{
"id": "range_18_24",
"count": 678,
"percentage": 10.4
},
{
"id": "range_25_34",
"count": 3289,
"percentage": 50.6
},
{
"id": "range_35_44",
"count": 1901,
"percentage": 29.2
},
{
"id": "range_45_54",
"count": 433,
"percentage": 6.7
},
{
"id": "range_55_64",
"count": 83,
"percentage": 1.3
},
{
"id": "range_more_than_65",
"count": 18,
"percentage": 0.3
}
]
},
{
"type": "gender",
"id": "male",
"buckets": [
{
"id": "range_less_than_10",
"count": 3,
"percentage": 0
},
{
"id": "range_10_18",
"count": 95,
"percentage": 1.5
}
// etc.
]
},
{
"type": "gender",
"id": "non_binary",
"buckets": [
// ...
]
}
]
}
}
}
}
}
}
The current Mongo aggregation pipeline is fairly simple:
const pipeline = [
{
$match: match
},
{
$unwind: {
path: `$${key}`
}
},
{
$group: {
_id: {
id: `$${key}`,
year: '$year'
},
count: { $sum: 1 }
}
},
{
$project: {
_id: 0,
id: '$_id.id',
year: '$_id.year',
count: 1
}
},
{ $sort: { [sort]: order } }
]
I'm guessing I need to add a second $group
stage, but I'm not quite sure how to do it…
Also note that the facet that items are grouped by will be set dynamically (or can be empty, in which case the facets
array would just contain a single element with "type": "default"
and "id": "default"
).
I'm struggling a bit to figure out the correct mongo aggregations to achieve this:
Data for the 8-player tournament bracket-style questions is stored in the following format, where each triplet is of the form [first player, second player, winner]
:
const bracketResult = [
[7, 6, 6], // first round
[4, 0, 0], // first round
[5, 2, 2], // first round
[3, 1, 3], // first round
[6, 0, 6], // semi-finals
[2, 3, 3], // semi-finals
[6, 3, 6], // finals
];
I would like to output two different data views.
In this view, each player would have the following stats:
So we would end up with an 8-item array, where each item has these eight datapoints. For example:
{
id: 'player_A',
overall: {
count: 123,
percentage: 23
},
round1: {
count: 123,
percentage: 23
},
round2: {
count: 123,
percentage: 23
},
round3: {
count: 123,
percentage: 23
}
}
(I've already managed to calculate the total number of wins by the way)
In this view, a given Player A would have the following stats:
So we would end up with eight 7-item arrays. For example:
{
id: 'player_A',
matchups: [
{
id: 'player_B',
wins: 123,
percentage: 23
},
{
id: 'player_C',
wins: 123,
percentage: 23
}
// etc.
]
}
When I use the graphql API and attempt to filter by either company size or year of experience, I am returned a response that is the same as if no filter parameters had been submitted.
It appears that the issue may likely lie in your filters.js file here (lines 83-84, 88-89)
https://github.com/StateOfJS/state-of-js-graphql-results-api/blob/413b6a07b3ac38cead184823311892ebdad756a3/src/filters.ts
It seems like these two variables didn't get switched from camelCase to snake_case. This is repeated up in the interface definition as well. (Lines 16-17 of the same file)
We only need to add the hacktoberfest
topic to the repo (instructions). I don't know if it's possible, but it would be cool to participate in the event this year 🙂
We are hoping to expose our internal GraphQL API publicly in the future. The main requirement would be adding a solid caching layer first.
A part of files are translated.
一部のファイルは翻訳済みです。
To avoid conflicts, I made a translation list .
If you want to contribute Japanese translation, please let us know here!
コンフリクトを避けるため、翻訳リストを作りました。
もし翻訳に貢献したい場合、ぜひここで知らせてください!
(I'm opening this thread here even though it's more about the results UI because it's not really specific to any given results repo)
No matter which demographics we reach with the survey, we'll always have minoritized segments by definition. The issue is that these segments then get drowned out by the majority, and you can't always hear their voices. For example, if e.g. a JavaScript library was especially popular in a given country, or did a really great job reaching out to women, that wouldn't necessarily be reflected in the current survey results.
The solution would be a filtering/querying UI somewhat similar to the Mac OS search dialog, for example.
Ideally, we'd support any combination of filters. At the same time, we can anticipate some filters being the most used (non-male, non-white, etc.) and it would make sense not to require people to re-specify them manually each time.
It'd be great to support in
, not in
, equal to
, etc. operators for filtering.
Do we want to compare chart A to chart B, or else within a single chart compare different datasets? In other words, having two different bar charts vs having a single bar chart with double bars for each datapoint (the first solution would be much easier to implement, the second one is not currently supported by the API and wouldn't work for some chart types).
If someone lives in China they probably want to add the "China" filter to every chart without having to manually specify it each time.
Ideally, each chart would preserve its filtering state in case of a page reload, component re-rendering, etc.
Can every filter be applied to every chart? How do we account for e.g. filtering the "gender identity" chart by "gender identity"? Disable it, return an error?
Can we make the filtered charts shareable? Generating a dynamic thumbnail preview seems hard, but we can probably at least make them linkable? This means loading state via the URL?
What I currently have in mind would be a system that provides predefined presets in combination with the ability to create your own custom filters. Ideally, once a custom filter is created it would then be available as a preset for all other charts to save people time.
There are still quite a few resources not properly formatted and/or linked up on:
https://2019.stateofjs.com/resources/
As well as a few other tools on:
https://2019.stateofjs.com/other-tools/
If you'd like to help you can submit a PR to add the missing items to this file:
https://github.com/StateOfJS/state-of-js-graphql-results-api/blob/master/src/data/entities.yml
Following this structure:
- id: syntaxfm
name: Syntax
homepage: https://syntax.fm/
description: A great podcast
category: podcasts
Where id
is the character string used in the chart (some of them are truncated which makes copy/pasting them a bit harder, sorry… You can hover on the bar to see the full string).
name
will be used as the properly formatted name, and homepage
will optionally be the URL linked to. description
and category
are optional and not currently used but we might use them in the future if we want to build out a more fleshed out directory of JavaScript resources.
Note that once a PR is merged to add in more resources, we still need to manually clear the API cache and rebuild the site before the changes are live, so it won't be instant.
Important: to avoid many people doing overlapping work please post here indicating which block's resources (Other Blogs & Magazines, Podcasts etc.) you want to work on and make sure nobody else is working on that first.
For all the Dutchy out there, let's translate!
Voor alle Nederlanders onder ons, laten we vertalen!
File | Author | Status | DONE? |
---|---|---|---|
accounts.yml |
@MaxAltena | DONE | ✔️ |
common.yml |
@MaxAltena | DONE | ✔️ |
homepage.yml |
@MaxAltena | DONE | ✔️ |
results.yml |
@MaxAltena | DONE | ✔️ |
state_of_css_2020.yml |
@MaxAltena | DONE | ✔️ |
state_of_css.yml |
@MaxAltena | DONE | ✔️ |
state_of_js_2020_survey.yml |
@MaxAltena | DONE | ✔️ |
state_of_js_2020.yml |
@MaxAltena | DONE | ✔️ |
state_of_js.yml |
@MaxAltena | DONE | ✔️ |
surveys.yml |
@MaxAltena | DONE | ✔️ |
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.