hiposfer / hive

Your go-to routing app for public transport
GNU Lesser General Public License v3.0
10 stars 0 forks source link

Consider moving non-layout styles to separate non-clj files #129

Open mehdisadeghi opened 6 years ago

mehdisadeghi commented 6 years ago

There are two types of CSS rules in our cljs files: layout rules and non-layout rules. I suggest to move all non-layout CSS rules to separate sass files or similar, where we can modify them and update branding colors and styles without having to touch clj source files.

carocad commented 6 years ago

@mehdisadeghi is this about moving the styles to separate files to have a sort of branding style? or about moving the styles out of clojurescript.

I think we should pick one of the two objectives but not both since I consider them contradictory in our case. The problem is that if we define the styles in json files then you would have to use them like

[:> react/View {:style (js->clj my-style :keywordize-keys true)}]

Which is a pain to use for developers.

On the other hand if we define the styles in clojurescript files like

(def my-style {:color "blue" :width 10})

It would be very easy to use for developers but changing it would require a bit of clojurescript knowledge.

mehdisadeghi commented 6 years ago

or about moving the styles out of clojurescript

I was thinking of moving them out of clojurescript, in a practical way. If separate style clojurescript files is the way to go I'm fine with that.

The main idea is hard-coding layout while letting colors and other non-layout styles to be defined separately and modified independently. In old-fashoned web it is possible with using CSS selectors, however I don't know how one can do it in cljs or react-native.

carocad commented 6 years ago

I was thinking of moving them out of clojurescript, in a practical way

I think we might also be able to get around from this by having a single style variable with all styles inside. Like:

(def style (js->clj (js/require 'myStyles.json') :keywordize true))

;;; in another file
[:> react/View {:style (:round-button brand/style)}]

which reads much better than the one above and it not that curversome to use :)

On another topic, and sorry for the ignorance. Could you explain to me what you mean by layout vs non-layout definitions? to be honest I have only bare knowledge of UI concepts so I just go and build the stuff without worriying too much about it, so obviously it is not the most structured way 😅

mehdisadeghi commented 6 years ago

I think we might also be able to get around from this by having a single style variable with all styles inside.

It sounds good to me.

Could you explain to me what you mean by layout vs non-layout definitions?

Sure! By layout I mean any CSS rule that defines where things should be positioned/displayed. By non-layout I mean the rules that only change the aesthetics of the elements and not their existence and positioning :)

to be honest I have only bare knowledge of UI concepts

Don't worry! Me neither :sweat_smile:

In some front-end projects (to the extent that I know) people use variables in sass to define brand-colors and some repetitive variables, afterwards they use those variables all over the code to style their elements. So if they change a brand color in the main file it will be reflected everywhere in the code.

carocad commented 6 years ago

I agree with this. But I think I would wait until you show me some examples of this to get on board.

PR welcome :)