React templating for Meteor
License: Other
Static site generated from React components.
For an overview of the project structure please refer to the Gatsby documentation - Building with Components
npm run build
npm run deploy
or
npm run publish
I'm getting this error:
/Users/Julian/.meteor/packages/timbrandin_blaze-react/.0.4.0.1gugxke++os+web.browser+web.cordova/plugin.blaze-react.os/npm/blaze-react/node_modules/xregexp/xregexp-all.js:2253:23:
Any idea why, or what might be going wrong?
On a side-note, what's the plan for the future of this package? Is this the 'easiest' way to use react as blaze? Is sideburns deprecated in favor of this?
Thanks!
There has not been any pulse in the last few months. The Readme says though that it is in constant development, and a preview release is on the way. What is the actual status then? @timbrandin, can you please help us.
https://github.com/stevenvachon/handlebars-react
that may help you.
here's another, but for more general templating:
where help docs?
I like initial ideas of components based Blaze2 and what Blaze Components try to do. React may be much better platform to that that Blaze. I understand that fist of all you wanted to make people more easy way of moving they apps into react so you wanted to be as stict with Blaze API as possible. Have you any plans to add components support into sideburns?
I'd like to have code like this:
<template name="Page">
<div class="page">
<ul>
{{#each person in people}}
<li onClick={{this.clickEvent}}>Hello {{person.name}}</li>
{{/each}}
</ul>
</div>
</template>
class Page extends React.Component {
mixins: [ReactMeteorData],
getMeteorData() {
return {
people() {
return People.find();
}
}
},
clickEvent() {
console.log('Hello world');
},
render() { return Template.Page }
}Is it possible in any way?
This looks amazing. A few questions that aren't covered in the ReadMe and maybe could be.
Will this be any slower than plain React itself? Or is this simply syntactic sugar that gets converted into React's normal syntax using Meteor's build pipeline?
When sideburns is fully developed, will it have any notable limitations compared to using regular React? And if so, is it possible to use regular React syntax for some components and sideburns for others in the same project?
So, it seems like react doesnt have the same kind of event listeners as meteor meaning there isnt a way to say if this component is click on this element then perform blah. Instead the event is tracked directly from the element using onClick, onScroll, ... onBlah. Well this means that the event listener should be directly tied to the element not its parents so it should react faster I would assume since it doesnt need to bubble down?
with this being said it kinda of make since and forces you to build your app into to components like so.
Here is a simple carousel component
<template name="Carousel">
<ul class="carousel">
{
this.props.photos.map(function(val, index) {
return <CarouselImage key={index} val={val} />
})
}
</ul>
</template>
and here is the image component of the carousel
<template name="CarouselImage">
<li onClick={Template.CarouselImage.events.click.bind(null, this.props)}><img src={this.props.val.photo} ref="image" /></li>
</template>
Be making each part of the carousel a component I am able to loop through the data binding onClick={Template.CarouselImage.events.click.bind(null, this.props)}
which looks like this
Template.CarouselImage.events = {
'click' : function (props) {
}
}
In order to get this simple and logical approach working I only had to add one line to the compiler
jsx += " events: function(o) {return this._events = o || (this._events || {})},\n";
What do you think?
What is the license on this project? I don't see a LICENSE.* file anywhere.
Thanks!
We need to update the documentation on the Readme, so it's easy getting started and for people to know how far we are from a release they can use.
I'm also using the meteor-ionic package and would like to have support of content blocks.
Hoping to have this feature!
reference: https://www.discovermeteor.com/blog/spacebars-secrets-exploring-meteor-new-templating-engine/
Sincerely,
txs
I just started looking at it, so i dont know whats in there, but perhaps we can glean some ideas. I posted quite a bit in the meteor forums, and hopefully MDG's @yyx990803 comes and joins us soon. I would like to use your repo as a forum to discuss the vision I have for this whole thing. If that's not okay, let me know, given that you created the package, and I think you should get credit as the main package owner as long as possible. At this point we may have differing visions (I don't know, you haven't told me much), but you seemed to have liked a lot of what i proposed or you wouldn't have done so much of it last weekend.
...then take the generated code that looks like this:
(function(){
Template.__checkName("action_buttons");
Template["action_buttons"] = new Template("Template.action_buttons", (function() {
var view = this;
return HTML.DIV({
"class": "action-button-container"
}, "\n ", HTML.DIV({
"class": "small-action-buttons"
}, "\n ", Blaze.If(function() {
return Spacebars.dataMustache(Spacebars.dot(view.lookup("currentUser"), "allowedTool"), "back");
and turn that into JSX. That will solve what will likely be a never-ending battle of transpiling a million spacebars edge cases.
I'm assuming by "Blaze Helper Context" in the checklist you're referring to these very things. @Twintailsx happened to have just been working on callbacks/autorun/subscribe/etc and they all revolve around this:
reohjs@3ccb4ac#diff-ca7c825ad21ebd08da3fae2ace49a2baR53
I noticed he wasn't using the static singleton context of Template[name] rather than a true instance context. That actually can be fixed easily for the callbacks and therefore autorun/subscribe. But for the other places mentioned in the title of this post, it's more complex--how do you think we best can do that? What path have you been thinking of?
It seems the context ( https://github.com/timbrandin/sideburns/blob/devel/template.jsx#L63 ) passed into templates has helper methods whose context is the component itself ( https://github.com/timbrandin/sideburns/blob/devel/template.jsx#L27 ). But that context really needs to be the true "data" context, which itself is a combination of this.data from getMeteorUserData, with contexts, each contexts, and props when the context is setup via a template inclusion. Now only after that is addressed, can we get to the "component" context of Template.instance() and the 2nd param in event handlers (whose context is the current incorrect context being passed in, that of the react component instance--so addressing that should be a lot easier in fact).
Tell me if I'm wrong about any of these things. It basically seems the stage we are at is we have the helpers being passed along, but their data contexts isn't being properly set, which is a challenging job since it can come from so many places. It seems to me one possible path is implementing a lookup() method much like Blaze which checks all these places, and we have a regex replace that injects just RT.lookup(), thereby achieving what seems your goal of keeping the actual transpilation to a minimum (so we dont suffer death by brittle regexes).
meteor add timbrandin:blaze-react --allow-incompatible-update
=> Errors while adding packages:
While selecting package versions:
error: Conflict: Constraint [email protected]_1 is not satisfied by babel-compiler 6.6.4.
Constraints on package "babel-compiler":
* babel-compiler@=6.6.4 <- top level
* [email protected] <- ecmascript 0.4.3
* [email protected]_1 <- timbrandin:blaze-react 0.4.0
meteor add timbrandin:blaze-react
=> Errors while parsing arguments:
While adding package timbrandin:blaze-react:
error: no such package
This really looks so good.
Or make React Components. :-) With the same API as Blaze Components.
So how I see Blaze is that it is just an engine which renders a reactive state to DOM. An React is a similar engine. How exactly is then API build for components on top of it is then something which can be adapted. So it would be great to make the API the same (template language, class structure), just the rendering would be different and then we could really compare them. Or even use one where each of them are stronger.
@timbrandin Tim, so i made the lookups + event handlers mixins you need:
LOOKUP:
https://github.com/ultimatejs/helper-lookup-blaze-react
EVENTS:
https://github.com/ultimatejs/event-selector-blaze-react
note: I used a similar solution to what you did with event listeners for events.
REACTIVITY:
https://github.com/ultimatejs/tracker-react
TrackerReact basically makes it so you don't need all the various hacks related to this:
https://github.com/timbrandin/blaze-react/blob/devel/lib/blaze-react.jsx#L59
It allows for the whole system to behave way more naturally. In, short, if you use all 3 of these mixins, all that must happens is basic recursive spacebars transpilation.
Basically, we need to use the above code because there are the following major issues with your lookup strategy:
../.. and Template.parentData(level)this.__lookup() with reactivity handled separatelySo I added support for custom block helpers. And along the way I realized: if we made {{#each}} a block helper, eg: <Each> it would simultaneously solve block helper lookups + each looping context, and generally make parsing simpler. Basically it means you never need to generate JS constructs such as if, else, map, loops, etc. In handlebars, everything is either an HTML element, or a Block Helper. So we replicate that by making components for all the Handlebars block helpers. I think that is the correct approach. Check this:
/**
* HERE'S HOW WE TRANSPILE AN #each BLOCK:
*
* let contentBlock = function() { return <CONTENT_BETWEEN_#EACH_AND_ELSE_OR_/EACH />; } ;
* let elseBlock = function() { return <CONTENT_BETWEEN_ELSE_AND_/EACH />; ;
*
* <Each parent={this} data={this.__lookup'($1', [$2])} contentBlock={contentBlock} elseBlock={elseBlock} />
**/
Each = React.createClass({
mixins: [HandlebarsMixin],
renderFunc() {
let {data, parent, contentBlock, elseBlock} = this.props;
if(_.isArray(data) && !_.isEmpty(data)) {
return data.map((item, index) => {
return this._contentBlockWithData(contentBlock, parent, item);
});
}
else return elseBlock.call(parent); //i.e. where block was defined
}
});
Now imagine a custom block helper ("UnlessSpecial"). Here's what the calling code would look like in both handlebars and jsx:
---------HANDLEBARS---------
{{#UnlessSpecial true}}
<div>something falsey - {{parentScopeProp}}</div>
{{else}}
<div>someting truthy - {{parentScopeProp}}</div>
{{/unless}}
------------JSX-------------
<UnlessSpecial data={true} parent={this}
contentBlock={() => <div>something falsey - {this.__lookup('parentScopeProp')}</div> }
elseBlock={() => <div>something truthy - {this.__lookup('parentScopeProp')}</div> }
/>
To see all my _base Handlebars Components_, check this file:
https://github.com/ultimatejs/helper-lookup-blaze-react/blob/master/handlebars-components.js
...Notice how the generated JSX has no real javascript. There is very close parity between Handlebars syntax and the necessary JSX code. This will enable the most seamless transpilation.
Also note how parent={this} is passed to all child components. It's needed to allow for ../../ and Template.parentData() AND to access data contexts by leaping over wrapper components such as Each, With, etc. It's very handy to have access to a linked list of your ancestors! It's also the one of the main differences between Handlebars and React. We can't make a complete Handlebars/Spacebars transpiler without it. In addition, I've done tests, and it doesn't break React. Why would it? It's just a reference to a parent. If the parent is forced to update, the child is forced to update as well. Therefore the reference is always correct, and you aren't introducing side-effects into the child component. These features are at the core of my Mixins that I'm releasing to the Meteor community for React on Monday, unrelated to Blaze-React.
You will also notice that you don't have to do complex hard-to-track context passing. Because the transpiler links all components to their parent, we can always traverse the tree backwards to discover context.
Examine the code here thoroughly. You're gonna basically see that we have good separation of concerns now, and likely this is the way it should be, but most importantly that no work needs to be done besides professional transpilation of spacebars.
So that brings me to the final points. I'm not sure xregexp will cut it.
Here's my research:
I don't even think MDG will try to use their Blaze parser anymore, if Babel has the capability to parse HTML. It doesn't make sense to parse Spacebars separately since Babel is now handling most everything else. Babel is likely better and faster than whatever they were doing. Babel can be very efficient because transformer plugins can modify the same AST, while the parsing and code generation steps happening just once. It's very efficient and will result in less steps. There's also a simple place where we can place a "visitor" to transform the code. We just need to figure out how to write it. It will be passed the nodes of the AST perfectly. I'm studying how to build Babel plugins currently and I think you should to:
https://github.com/thejameskyle/babel-plugin-handbook
I know you exchanged a few words with MDG, but those guys aren't doing anything in this area yet. It was just an announcement in response to pressure. They're busy as hell with other things. In addition, they likely won't do it correctly. At least at the moment, they haven't exhibited the proper vision for this. As it is, they don't even believe your project is possible. Anyway, we can't count on them. We need to make this, and we should make it the professional way. The way that will stand the test of time. The way they will proudly incorporate into their codebase.
...Im gonna release my mixins for React over the next few days. I didn't release them earlier in the week as I said because I wanted to make sure they matched with the similar mixins I would give you today. In short, we are moving the entire meteor community into the proper complete integration of Meteor + React. The only thing that will be remaining is the transpiler.
WE NEED TO FIGURE OUT HOW TO WORK TOGETHER TO GET TRANSPILATION DONE. AND MY SENSE IS THE RECURSIVE REGEX PATH WILL NOT WORK. My sense is either a Babel plugin or contributing to https://github.com/stevenvachon/handlebars-html-parser is the path forward.
Either way, look in my code linked above. I provide precise examples of how the outputed JSX code should look. We need to work together to achieve that.
OUR HOMEWORK:
A) https://github.com/thejameskyle/babel-plugin-handbook
B) https://github.com/stevenvachon/handlebars-html-parser
_which path should we take?_
I believe the react equivalent to onRendered is componentDidMount so is this something we could append to getMeteorData or something during compilation?
This package is really amazing, thank you for putting it together. I really wish I could use it!
It would be nice if this package could co-exist with templating & ecmascript -- for those migrating to react. The only way I can think of this is by renaming the file extensions.
essentially we gotta generate getMeteorData methods that return the data the template reactively depends on. The this.data context Meteor uses is called "Sideways-loading" data. Meteor isn't the first to do it. A few other complimentary React tools use the data property, and React is working on making an official implementation for sideways loading data:
So that's basically what Meteor is already doing, and what we need to automatically generate so that components get triggered to update themselves, similar to how they do when you call this.setState(). The ReactMeteorData mixin essentially triggers the template to update itself when Tracker indicates the subscribed data has changed.
I wonder if we can dynamically add/modify that method during execution. We won't know what cursors are being created until runtime. We could guess a lot statically, but I think this is one we gotta sit out trying to figure out statically, unlike events where it's worth it. This one we gotta do completely dynamically or not at all. But I actually think we can do it easily dynamically. Cursors serve the perfect vehicle. They describe precisely the data dependent on. What we do is wrap all find/findOne calls, etc, and analyze the cursor as it passes through our code, and then in the cursor dynamically change the getMeteorMethod and trigger it to return again, notifying the rest of the system to reactively use it instead of the old one. The latter part is the unknown we gotta figure out, but something tells me the answer will be affirmative and the harder part will be writing the wrapper functions--like you did over the weekend with writeFile.
The main thing is we gotta know what component our find calls are executing in. We could do what meteor does with tracker and put into the global scope a variable that tells u the currently being executed component. We override all the componentWillMount/Unmount calls to tell us this. It basically is gonna do exactly what Tracker does--cuz check it: tracker only can reactively depend on "live" code that is called within a function, that is not code that was never triggered in an else block; so similarly we must rewrite the getMeteorData method every time methods of its component are called since new cursors might be used and old ones not used. Hell, we may find it easier to rewrite what getMeteorData itself does. Cuz it's basically doing something like this--it's triggering an update based on cursors used in it. Well, we gotta trigger an update based on cursors used in any damn helper method. Performance wise, I dont see it as being that much bigger--I don't see why Meteor didn't do it this way to begin with. But even if performance does suffer, it's not a big deal as long as it works. We have to keep in mind this is more about the transition from Blaze to React. That's what production apps will end up doing anyway--rewriting performance-intensive areas, but using the "lead" we gave them by generating React components that aren't far off from their manual more performance-optimized versions. What I'm saying is React clearly allows for side-ways loading data. It likely leads to entire branches of the tree re-rendering, unlike the props-based mechanism they advocate for which which does not (i.e. "dumb components"). Nevertheless, it will work! And that's all that matters. Especially when we get it to work with React Native. At the end of the day Clojurescript's Om performs way faster than standard React because it insures all the data is truly immutable. React does not. So in Om React object comparisons by reference are all that's needed all the way down the tree, which is a lot faster than standard React's shallow object comparisons, i.e. whether to determine to just re-render the component as it was the last re-render.
So anyway, getting this to work is priority. Not performance. Performance can easily be optimized by those willing to permanently transpile our code and start using the lovely React components we generated for them--i.e. rather than continue to transpile blaze code as a build step. ..We need to do whatever it takes to intercept the reactive cursors + sessions in helper methods, and then force updates on the component whenever our interceptor gets notified from tracker. We'll likely drop the ReactMeteorData mixin altogether and incorporate this completer reactivity in our mixin. ..that said, my components system has basically a subscription Relay-style ORM built into any component you want to add it to, and that's the recommended way of subscribing to data. So once again, the Components-based version of Blaze will come to the rescue if we can't solve this in plain Blaze.
Blaze will rerender the top down passing parameters if the props and states change. So kadira have a project called blaze-plus. Does this happen to sideburn? https://github.com/kadirahq/blaze-plus
Check it, I just released this package:
https://github.com/ultimatejs/tracker-react
Here's an example you can get up an running with a few commands:
https://github.com/ultimatejs/tracker-react-todos-example
Basically, I'm starting to solve a lot of the dynamic behavior we talked about. BUT, the way I'm introducing it s by building it as upgrades to React for Meteor in the form of mixins. This first mixin solves the reactive helper issue (i.e. allowing reactivity beyond just getMeteorData ie. in actual methods). The next one will be the events one, which I posted jsfiddle research the other day for proving its possible. With those 2 things, plus your spacebars transpilation, we can put all the pieces together and make Blaze 1.0 fully renderable in Blaze.
So, you were right, we don't need to transpile the events .js files. I can--and HAVE TO--do it dynamically at run/render time.
That means all i need is a map of template names containing their rendered jsx code. No cheerio for attaching events, no tranpsiling it. And also no helper context stuff. I have to do all that super dynamically at render time. It will be easiest for me if I have a nice spacebars package (maybe called timbrandin/spacebars-react which you can take credit for). All you have to do when you encounter variables is: this._lookup('foo.bar.etc'). I'll take it from there.
So in short, the only that must be done, is remove all the stuff I just mentioned and then complete the regexes for these 4 things:
And then export SpacebarsTemplates as a map of JSX render functions.
You have a lot more experience with those regexes than I do, I'm sure you can do them way quicker than I can. I know you're busy as hell. I'll do this after I finish dynamic selector-based Event binding, but I figured you may wanna make your mark here. The plain spacebars transpiler will surely become widely used (and further optimized) since many similar such packages can depend on it. So I think it's important it stands alone and is included by the packages that deal with the dynamic behavior. I know I recommended close to the opposite like a week ago. But I'm not saying remove it from Sideburns--unless you want to--but strip it on its own and complete it so it can start to be used today.
The other thing to note if it's not clear is this: we are basically making what the MDG CEO mentioned the other day. We aren't aiming for the loftier goal of rendering all of Blaze 1. Not yet. We are making the optimum Blaze 2 for React. I.e. the optimum React integration for Meteor. After this is achieved we will circle back and render blaze 1. It will be simpler then. But it's in fact easier to make the optimum React-Meteor, so we might as well make that and get that into people's hands sooner. I'm already launching the first part today. So since we can do it piece by piece (mixin by mixin, and eventually your spacebars transpiler) we can sooner get eyes on it and feedback. This will ultimately help guide MDG to make the right decisions about their final implementation--perhaps our work will become it.
I'm wondering, what solution would you recommend for making Sideburns work with meteor-jade package? Would that even be possible or is it too many abstraction layers to be worth implementing?
I have been using velocity js within my on rendered code. Do you think it would work as is with your solution?
Hi, I'm receiving this error after adding this package to a new 1.2.1 meteor project running on Windows 7:
Packages are:
timbrandin:sideburns
kadira:flow-router-ssr
I had a look at the jsx package but still not even sure where to start with debugging this... any ideas?
Regarding passing down events to children from Phase 2, I found this:
http://www.bennadel.com/blog/2916-attaching-dynamic-event-handlers-to-proxied-child-elements-in-reactjs.htm (check the video around 5:30)
Basically what they are doing is cloning the element and passing down event handlers, though I'm not sure how Blaze passes down the event handlers. I suspect they get attached to the matching DOM element in the Template, that could get tricky!
you could do it in a build plugin or a wrapper around React.Component. I'm not sure how you're building sideburns, but is React.Component actually pure React or is it your own wrapped version?
..Anyway, I think making react look as much like blaze as possible and vice versa will go a long way to quell the concerns over the "React Fiasco." Excellent Job/Idea!!!!
Hi,
Would you be able to create a new repo that performs a similar task where instead of converting everything to the final .js files it converts the html.jsx just to .jsx? This would be great so that I can transition an existing project to .jsx as I learn to write jsx. Perhaps just a command line node version of the program? Thanks. 👍
Hi
I recently updated my sideburns-version and started to get error "Cannot call method 'helpers' of undefined". I think the problem is that sideburns not parses the template nodes correctly, should I do something special to initiate sideburns / blaze-react in the newest version?
so i tested the context feature of React and whether we could make a parentData feature. And guess what! We can:
http://jsfiddle.net/Ljpd0d0m
scan down to the JamesBox component.
I was worried that the parentData wouldnt be updated if accessed via this.parent.props.foo or this.parent.props.parent.props.parent.props.bar`. See what I'm saying. But that stuff is all staying up to date on its own. I.e. the parent props will be up to date. So there's no reason you can't harmlessly access them from child components.
@aldeed 's very popular AutoForm package uses Template.parentData and likely ../../etc spacebars expressions. For that stuff to work we have to have this feature, and we do!
...As for React's context feature--that works as planned too. Click the "INCREMENT ALL" button in the example to watch the color context value propagate down to any components that set it as a contextType. That's how we can pass the events down early on until we need dynamic css selectors + full-page selector capacity. It's also the precise way my Blaze 2.0 package will pass down helpers. So even if that doesn't end up being part of the final solution for events, it's super major for helpers. I'm planning on making my components package really popular--and if all this comes together, it will be; with react integration like so, it will be the defacto Blaze 2.0 Components package.
We need to better describe our methods, so it's easier getting started improving this.
for example to do basic math + logic in templates to achieve the canonical example of striping some table rows (based on an index):
<table>
{{#each item in items}}
<tr class="{{@index % 2 ? 'odd' : 'even'}}"></tr>
{{/each}}
</table>
It seems it might be easier to achieve this here then in actual spacebars. Might be a good time/place to get these much in-demand features. Of course you first must add @index (which arrived in Meteor 1.2) to your to do list.
we just need to change the values of expected to be what our transpiler will output.
@Twintailsx you may be interested in this aspect.
Hey Tim, here's a proposal I put together of what we can do to organize this better to make it easier for new developers to contribute:
https://gist.github.com/faceyspacey/e7498f808876548f394d
Here's a public to do list comprising it:
https://docs.google.com/spreadsheets/d/1q6d4VEv6hnZlwH3Fi_jbTYAp1c50A9srMguijvCbedg/edit#gid=0
It's all based on the less formal and disorganized exploration here:
https://github.com/timbrandin/react-templates/pull/1/files#r44759084
Basically you can skip that if you want and move directly to the gist and spreadsheet.
Hi,
First of all love the concept of this package.
Second I am having some troubles getting an "each in" loop to work.
It Iterates through my mongo collection but {{ item.text }} isn't printed.
example:
<template name="Page">
<div>
<h1>{{test}}</h1>
<ul>
{{#each item in getItems}}
<li>{{item.text}}</li>
{{/each}}
</ul>
</div>
</template>
Template.Page.onCreated(function() {
this.name = new ReactiveVar('foo');
this.items = People.find();
});
Template.Page.helpers({
getItems(){
return this.items.fetch();
},
test(){
return this.name.get();
}
})
Template.Page.events({
'click .test': function() {
this.name.set("bar");
}
});The reactivevar is showing up perfectly so it must be somethings specific to "each in" loops.
I'll try to investigate your package myself but any help would be great :).
For some reason my templates are being complied into react elements?
I have this template named like main.html.jsx
and the code looks like this
<template name="MainTemplate">
<div class="main-container">
</div>
</template>
but when it compiles I am seeing the following
(function(){React.createElement(
"template",
{ name: "MainTemplate" },
React.createElement("div", { "class": "main-container" })
);
})();
any idea?
I added react to my project in order to use FlowRouter with react components
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.