Fork me on GitHub
#reagent
<
2016-08-01
>
thomas09:08:38

@timothypratley @gadfly361 that sorted it…. it was indeed the r/atom problem. And I just realised that this was the first time I use this feature in my code…

gadfly36109:08:31

Oh good, glad you got it working!

thomas10:08:56

yes… works really cool… press a button and watch the table update it self according to the search criteria 🙂

hjrnunes11:08:38

hi guys, does anyone have a good suggestion on how to do i18n with cljs?

gadfly36112:08:17

@hjrnunes: Not sure if this is the best way, but here is more or less what I have done before. - Create a folder called lang, and inside of that create a namespace for each language you wish to support. - Inside of each namespace, create a map with key-value pairs for the text you wish to render to the page. Where the value is the text for that specific language - In app-state, have a key that defines which language to use, and then insert the appropriate language's map into app-state - In your views, subscribe to the keywords of text to avoid hard coding any language specific text into your view This should allow you to hot-swap which language you wish to display at run time since it is all in app-state

hjrnunes12:08:59

@gadfly361: Thanks! Yeah, that’s pretty much what I came up with. It’s essentially doing Java’s i18n but with EDN rather than properties files. Was just checking whether people approached this differently and how. So you would use different namespaces and require all of those? Why that instead of a keyed by language map? Or even a keyed by by text then language? ex: {:en {:some_text “some text”}} or {:some_text {:en “some text"}}

gadfly36112:08:26

A keyed by language map is totally fine too. My very small concern is overloading app-state. For me, it isnt even a performance issue, just preference - find it easier to debug when 'less' is in app-state. So id rather have my app-state look like this:

{:lang :en
:text {:title "My Blog"
            :sub-title "clever. three. words."}}
than
{:en {:title "My Blog"
           :sub-title "clever. three. words"}
 :span {:title "Mi Blog"
               :sub-title "inteligentes. tres. palabras."}}

gadfly36112:08:44

regarding the namespace question, i would ... and there is nothing stopping you from putting all the maps into a single file ... i am namespace happy tho lol

hjrnunes12:08:38

yeah, that makes sense. I have no preference so just checking on whether there was any particular reason other than that

hjrnunes13:08:47

Hey, something else: what do people do to have “enter" submit forms and whatnot? Just handle on-key-press whenever appropriate? Create a specific input component with on-key-press support?

gadfly36113:08:08

@hjrnunes: I do something like this - create a form-3 component - use the following for will-mount and will-unmount

(defn enter->submit [e id-btn]
  (when (= 13 (.-charCode e))
    (-> js/document
        (.getElementById id-btn)
        .click)))

(defn component-will-mount [id-btn]
  (-> js/document
      (.addEventListener "keypress"
                         #(enter->submit % id-btn))))

(defn component-will-unmount [id-btn]
  (-> js/document
      (.removeEventListener "keypress"
                            #(enter->submit % id-btn))))
This does make two assumptions tho: 1) an enter in general should submit, 2) there is only one submit button on the page

hjrnunes13:08:55

@gadfly361: Good stuff! Thanks!

mihaelkonjevic13:08:42

@gadfly361 @hjrnunes if the input field is wrapped with the form element it should automatically submit on enter http://jsbin.com/jaronapibi/edit?html,output

hjrnunes14:08:03

@mihaelkonjevic: Ah cool! Yeah, I don’t consistently use :form. It’s kind of annoying actually. I can’t make up my mind in regards to that. Mostly I’ll use it when/if using bootstrap or semantic to style

hjrnunes14:08:08

But thanks!