Merge branch 'master' of https://github.com/status-im/wiki.status.im
This commit is contained in:
andmironov
commit
243462b02b
|
|
@ -1,82 +0,0 @@
|
|||
# Clojurescript
|
||||
|
||||
https://github.com/status-im/status-react
|
||||
|
||||
## Project Structure (out of date)
|
||||
1. The structure of the project was changed from
|
||||
```
|
||||
syng_im
|
||||
- handlers.cljs
|
||||
- subs.cljs
|
||||
- models
|
||||
- components
|
||||
- chats
|
||||
- contatcs
|
||||
- react.cljs
|
||||
```
|
||||
to
|
||||
```
|
||||
syng_im
|
||||
- chat
|
||||
- handlers.cljs
|
||||
- subs.cljs
|
||||
- views
|
||||
- styles
|
||||
- screen.cljs
|
||||
- contacts
|
||||
...
|
||||
....
|
||||
- components
|
||||
- handlers.cljs
|
||||
- subs.cljs
|
||||
```
|
||||
So previously `syng-im.handlers` ns contained all handlers, now it is the point where all handlers are required, and the place for very common handlers (like `:set`).
|
||||
`syng-im.subs` ns contained all subscriptions, but now it has to contain only common handlers, like `:get`. Everything specific to particular feature/screen (like `chat`/`contacts`/`navigation` etc), including specific handlers, subs, views etc. should be placed inside feature's dir. This helps to simplify reasoning about the particular feature by avoiding of mixing of code with unrelated functionality inside one namespace. We still have `components` which will contain common components and views like `text`/`view`/`carousel` etc, that can be used inside other `views`
|
||||
|
||||
2. Views must not contain any logic related to control on applications data (changing of state, specific validation/checks of data etc...). The only way to work with app-db inside views is to subscribe to particular data from app-db and dispatch events to handlers.
|
||||
|
||||
3. Styles. Views should be free of styles definitions but only reference to them. Everything related to presentation should be moved to `feature.styles`/`components.component-name.styles` ns. If there is any logic related to the presentation which should be computed based on data it is fine to write a function which will take that data as parameters and return styles.
|
||||
|
||||
4. Handlers. The idea is to keep handlers pure as far as it possible and don't mix code that contains side-effects with code that is pure. The code that contains `side-effects` shouldn't contain any application's logic. It means that if we have handler like
|
||||
```
|
||||
(register-handler :load-messages
|
||||
(-> load-messages!
|
||||
((enrich add-messages)))))
|
||||
```
|
||||
everything related to applications logic (like processing of messages after loading, adding messages to app-db, etc) should be placed inside `add-messages` function, when `load-messages!` only contains a call to external api/db/whatever outside app-db. In this case, all handlers which contain applications logic are pure and that means that they are testable (I hope we will get to tests once).
|
||||
|
||||
5. Subs. Nothing specific. Just keep them in right namespaces.
|
||||
|
||||
**Common things:**
|
||||
|
||||
1. Namespaces should not contain all other namespaces in `require` form. Just keep there namespaces/refers that are really used.
|
||||
|
||||
2. Models shouldn't contain any logic wich not related to fetching data from db.
|
||||
|
||||
3. There is no need to gather "paths" inside `syng-im.db` ns. This only leads to coupled code with a lot of senseless references. For instance to code like this
|
||||
```
|
||||
(register-handler :change-message
|
||||
(fn [db [_ message]]
|
||||
(change-message db message)))
|
||||
|
||||
(defn change-message [db message]
|
||||
(assoc-in db (message-path (get-current-chat-id id)) message))
|
||||
|
||||
(defn message-path [chat-id]
|
||||
[:chats chat-id :message])
|
||||
|
||||
(defn get-curent-chat-id [db]
|
||||
(get-in db current-chat-id-path))
|
||||
|
||||
(def current-chat-id-path :current-chat-id)
|
||||
```
|
||||
where these functions are placed in three different namespaces, when it can be just
|
||||
```
|
||||
(register-handler :change-message
|
||||
(fn [{:keys [current-chat-id] :as db} [_ message]]
|
||||
(assoc-in db [:chats current-chat-id :message] message)))
|
||||
```
|
||||
|
||||
4. Specific properties that are used everywhere for same components better to move to components definition than to repeat each time when a component is used. Like `:underlineColorAndroid :transparent` for `text-input`
|
||||
|
||||
And so on... Other things are more related to Clojure, not to application's or `re-frame`'s architecture.
|
||||
|
|
@ -1 +0,0 @@
|
|||
# Golang
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.8 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
|
|
@ -0,0 +1,106 @@
|
|||
# Introduction
|
||||
|
||||
In this post, you will learn what the two main languages used in Status are, how to learn them, how to build Status, & finally how to find tasks to work on.
|
||||
|
||||
Status is largely written in two languages: Clojurescript & Golang and builds on React Native for UI. I'll talk about the rational behind these design decisions and link to offsite resources on learning each of these technologies.
|
||||
|
||||
## React Native
|
||||
|
||||
Status (formerly known as Syng) has always aspired to have a single, unified codebase for multi-platform development. This is not so easy to achieve, as many of the non-web-based solutions out there allow you to have a semi-single codebase, but you find yourself creating a lot of seperate logic for handling user interfaces on each platform - Status is 80% frontend code and this presents a problem. We tried Xamarin & Java (EthereumJ was the first implementation we got running on Android & iOS - via RoboVM), and we quickly discovered this problem.
|
||||
|
||||
Mobile apps built on web-based technologies, such as those done in Cordova, are great for short-term projects or mvp, but you will quickly run into performance issues on resource-limited devices and may need to rewrite you app. In our tests displaying webview DApps in a chat history with iFrames and all the other bells and whistles we wanted turned out to be a futile effort.
|
||||
|
||||
That limited our options to choosing between NativeScript & React Native. We chose React Native because it is more mature and is being used in production for popular apps like **Facebook**, **Instagram**, **Airbnb**, **Baidu** & **Discord**. This gave us the impression that this framework was here to stay with many Fortune 500 companies invested in its continuance.
|
||||
|
||||
At this point all we had to do is merge Material & iOS design into our unique look'and'feel so that we could minimise the amount of Android & iOS specific code. Our amazing designer [Andrei Mironov](https://dribbble.com/andmironov) elegantly solved the rest of that puzzle.
|
||||
|
||||
### React Native Learning Resources
|
||||
|
||||
If you would like to start learning React Native, check out these resources:
|
||||
|
||||
- [Use React Native](http://www.reactnative.com/books/)
|
||||
- [React Native Docs](https://facebook.github.io/react-native/docs/getting-started.html)
|
||||
|
||||
Although you might want to continue reading and learn more about [re-natal](#re-natal), [re-frame](#re-frame) & [reagent](#reagent).
|
||||
|
||||
## Clojurescript
|
||||
|
||||
*“Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.”* — [Eric Raymond](https://en.wikipedia.org/wiki/Eric_S._Raymond).
|
||||
|
||||
To read more quotes on Lisp read [Lisp, made with secret alien technology](http://lispers.org/).
|
||||
|
||||
[](https://xkcd.com/224/ "We lost the documentation on quantum mechanics. You'll have to decode the regexes yourself.")
|
||||
|
||||
There's alot of resources online about why learning Lisps are so great. For us, it's largely about culture; we like the way Lispers think. We want functional programming, macros, homoiconic code and the flexibility that comes with a simple, unstructured language in which to think. The benefits of this become more apparent in later stage development, where functional language allows us to perform rewrites more easily, isolate many bugs to specific functions, as well as enforcing correct coding. Also, I prefer reading it.
|
||||
|
||||
Moreover, with [hiccup](https://github.com/weavejester/hiccup), working with React Native markup becomes a dream.
|
||||
|
||||
### Clojurescript Learning Resources
|
||||
|
||||
If you would like to start learning Clojurescript, check out these resources:
|
||||
|
||||
- [Clojurescript FAQ (for JavaScript developers)](https://github.com/clojure/clojurescript/wiki/FAQ-(for-JavaScript-developers))
|
||||
- [Clojurescript Community Resources](http://clojurescript.org/community/resources)
|
||||
- [Clojurescript Unraveled Book (Free)](http://funcool.github.io/clojurescript-unraveled/)
|
||||
- [/r/clojure](https://www.reddit.com/r/Clojure/) & [/r/clojurescript](https://www.reddit.com/r/Clojurescript/)
|
||||
|
||||
## Go
|
||||
|
||||
Of all the Ethereum implementations `go-ethereum` has received the most love and implements the newest and best features. Without `go-ethereum` we couldn't use the light client protocol and Status would not be possible. We will also get access to Swarm the fastest. We consume `go-ethereum` as a library in [status-go](https://github.com/status-im/status-go).
|
||||
|
||||
'Nough said.
|
||||
|
||||
## Re-natal
|
||||
|
||||
re-natal is an invaluable tool to that automates the setup of your [re-frame](#re-frame) React Native for Android & iOS, it includes [figwheel](https://github.com/decker405/figwheel-react-native) for easy development.
|
||||
|
||||
- re-natal [README.md](https://github.com/drapanjanas/re-natal)
|
||||
|
||||
## Re-frame
|
||||
|
||||
re-frame is simple but expressive library for writing Single Page Applications in ClojureScript, using [Reagent](#reagent). It is a functional framework for reactive 'MVC-style' applications. To learn more:
|
||||
|
||||
- re-frame [README.md](https://github.com/Day8/re-frame)
|
||||
- re-frame [docs](https://github.com/Day8/re-frame/tree/master/docs#introduction)
|
||||
- [A Noob's walkthrough of a re-frame Application](http://www.multunus.com/blog/2016/02/noobs-walkthrough-re-frame-app/)
|
||||
- [The Angular Phonecat tutorial in re-frame](https://dhruvp.github.io/2015/03/07/re-frame/)
|
||||
|
||||
## Reagent
|
||||
|
||||
[Reagent](http://reagent-project.github.io/) provides a minimalistic interface between ClojureScript and React. It allows you to define efficient React components using nothing but plain ClojureScript functions and data, that describe your UI using a Hiccup-like syntax.
|
||||
The goal of Reagent is to make it possible to define arbitrarily complex UIs using just a couple of basic concepts, and to be fast enough by default that you rarely have to care about performance.
|
||||
|
||||
- [Reagent website](http://reagent-project.github.io/)
|
||||
- Reagent [README.md](https://github.com/reagent-project/reagent)
|
||||
- [Building Single Page Apps with Reagent](https://yogthos.net/posts/2014-07-15-Building-Single-Page-Apps-with-Reagent.html)
|
||||
- [You should be using Figwheel & Reagent. Here's why](http://timothypratley.blogspot.com/2015/07/you-should-be-using-figwheelreagent.html)
|
||||
- [Reagent Rocks](http://www.mattgreer.org/articles/reagent-rocks/)
|
||||
|
||||
## Building Status
|
||||
|
||||
[Read our guide on how to Build Status](building-status.md)
|
||||
|
||||
## Finding issues to work on
|
||||
|
||||
So by now you should have a general sense of the tech that goes into Status, managed to get Status built & running and want to find something to sink your teeth into.
|
||||
|
||||
The best place to look for tasks to work on is our [Github Issues](https://github.com/status-im/status-react/issues). We've labelled the tasks by our estimated difficulty.
|
||||
|
||||
**Click the labels below to see what is available.**
|
||||
|
||||
|
||||
## Beginner Issues
|
||||
<a href="https://github.com/status-im/status-react/issues?q=is%3Aopen+is%3Aissue+label%3Abeginner" target="_blank"><img src="../img/beginner.png" style="height:28px;margin:0"/ ></a>
|
||||
|
||||
These are tickets we believe anyone willing to learn Clojurescript can handle. They involve minor UI and localisation changes. Even though they may seem minor that have a huge impact on the usability of Status.
|
||||
|
||||
## Intermediate Issues
|
||||
<a href="https://github.com/status-im/status-react/issues?q=is%3Aopen+is%3Aissue+label%3Aintermediate" target="_blank"><img src="../img/intermediate.png" style="height:28px;margin:0"/ ></a>
|
||||
|
||||
Beginner too easy and your Clojure-fu up to par? Time to level up!
|
||||
These issues require a slightly deeper understanding of what Status is trying to accomplish; an understanding of Ethereum; and more communication and intimacy in the Slack as they are interdependent tasks. They involve things like setting up UI tests, fixing nastier bugs and making decisions that will have a real impact on how Status behaves and functions.
|
||||
|
||||
## Advanced Issues
|
||||
<a href="https://github.com/status-im/status-react/issues?q=is%3Aopen+is%3Aissue+label%3Aadvanced" target="_blank"><img src="../img/advanced.png" style="height:28px;margin:0"/ ></a>
|
||||
|
||||
These issues are really there for people deeply into Ethereum, Core Contributors and people who believe in Status and have the skills to make magic happen.
|
||||
|
|
@ -94,6 +94,10 @@ Permissions are always a hot topic for apps, we hate the way we’re doing them
|
|||
|
||||
**Camera** — We use this for setting your profile picture and for reading QR codes.
|
||||
|
||||
## Where are the nightlies?
|
||||
|
||||
Here you go!
|
||||
http://artifacts.status.im:8081/artifactory/nightlies-local/
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -13,13 +13,12 @@ pages:
|
|||
- User Guide: 'getting-started/user-guide.md'
|
||||
- FAQ: 'getting-started/faq.md'
|
||||
- Code of Conduct: 'getting-started/code-of-conduct.md'
|
||||
- Building Status: 'contributing/development/building-status.md'
|
||||
- Developer Introduction: 'contributing/development/introduction.md'
|
||||
- Contributing:
|
||||
- Developers:
|
||||
- Introduction: 'contributing/development/introduction.md'
|
||||
- Building Status: 'contributing/development/building-status.md'
|
||||
- Adding DApps: 'contributing/development/adding-dapps.md'
|
||||
- Clojurescript: 'contributing/development/clojurescript.md'
|
||||
- Golang: 'contributing/development/golang.md'
|
||||
- UX & Design: 'contributing/ux-and-design.md'
|
||||
- Testing & Feedback: 'contributing/testing-and-feedback.md'
|
||||
- Documenting: 'contributing/documenting.md'
|
||||
|
|
|
|||
Loading…
Reference in New Issue