by Ossi Hanhinen, @ohanhi
with the support of Futurice 💚.
Licensed under CC BY 4.0.
import React from 'react'; | |
import { container } from 'redux-relay'; | |
@container({ | |
variablesFromState: (state) => ({myVariable: state.myState}) | |
fragments: { | |
Relay.QL` | |
viewer { |
function mapValues(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
result[key] = fn(obj[key], key); | |
return result; | |
}, {}); | |
} | |
function pick(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
if (fn(obj[key])) { |
2015-01-29 Unofficial Relay FAQ
Compilation of questions and answers about Relay from React.js Conf.
Disclaimer: I work on Relay at Facebook. Relay is a complex system on which we're iterating aggressively. I'll do my best here to provide accurate, useful answers, but the details are subject to change. I may also be wrong. Feedback and additional questions are welcome.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
# Hello, and welcome to makefile basics. | |
# | |
# You will learn why `make` is so great, and why, despite its "weird" syntax, | |
# it is actually a highly expressive, efficient, and powerful way to build | |
# programs. | |
# | |
# Once you're done here, go to | |
# http://www.gnu.org/software/make/manual/make.html | |
# to learn SOOOO much more. |
Availability and quality of developer tools are an important factor in the success of a programming language. C/C++ has remained dominant in the systems space in part because of the huge number of tools tailored to these lanaguages. Succesful modern languages have had excellent tool support (Java in particular, Scala, Javascript, etc.). Finally, LLVM has been successful in part because it is much easier to extend than GCC. So far, Rust has done pretty well with developer tools, we have a compiler which produces good quality code in reasonable time, good support for debug symbols which lets us leverage C++/lanaguge agnostic tools such as debuggers, profilers, etc., there are also syntax highlighting, cross-reference, code completion, and documentation tools.
In this document I want to layout what Rust tools exist and where to find them, highlight opportunities for tool developement in the short and long term, and start a discussion about where to focus our time an
The MIT License (MIT) | |
Copyright (c) 2014 Tomas Kafka | |
Permission is hereby granted, free of charge, to any person obtaining a copy | |
of this software and associated documentation files (the "Software"), to deal | |
in the Software without restriction, including without limitation the rights | |
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
copies of the Software, and to permit persons to whom the Software is | |
furnished to do so, subject to the following conditions: |
This is a response to Bill Fisher regarding experience with Flux:
@abdullin Also, can you clarify what you mean by "solution structure"? I am thinking about revising the examples soon.
Currently all flux samples (that I've seen) group files into folders based on technical similarity. For example, stores go with stores, action creators reside in the same folder shared with the other action creators.
This pattern works quite well for smaller projects. It feels especially good for the sample projects of various MVC frameworks, when you have just a bunch of controllers, models and views.
However, as we discovered on some production projects, such approach doesn't scale well. At some point you end up with dozens of technically similar files per folder and logically messy solution.