1. 2

    Related to this, Braintree has a rails example repo on github, which can be used as reference for what a mostly finished integration looks like https://github.com/braintree/braintree_rails_example

    1. 1

      Yeah! this Braintree example is really good!

    1. 2

      I don’t know much React, but there’s nearly nothing in here that helps me understand anything at all about what’s going on or where the meat of the implementation is. Seems like some tutorial code from somewhere else that’s been sprinkled with a bunch of not super useful comments.

      These is all useless text, they don’t give any ‘what / how / why / when’ information, so the reader is just copying and pasting huge chunks of code.

      We add immutable, because we will use immutable in our state.

      Also, we want to use flow, so, let’s run: flow init and it creates a .flowconfig file

      We have a stores file that contains all our stores we might have.

      Let’s make our item component draggable.

      Going through the long chunks of code there, are a few places where the actual implementation happens that need much deeper discussion, specifically under ‘Let’s make our item component draggable.’ and ‘Let’s see our DragDropReducer:’

      1. 1

        It was really a blog post meant for someone who knows the react and redux bits and just wants to see how to introduce drag and drop and integrate with redux. I could post a more detailed writeup for people less familiar with react, but those people aren’t likely to need drag and drop! But thanks for the feedback, I’ll try to keep it in mind for the next post!”

      1. 0

        nice article

        1. 0

          God forbid the API returns XML.

          1. 2

            I can try to cover XML in another blog post! Thanks for your feedback! ;)

            1. 2

              I made the comment because, last time I looked, there were not decoders for XML available in ELM. Good article.

              1. 1

                I’m thinking about that and searchinng… Then I found a question from you: https://stackoverflow.com/questions/40097133/parsing-xml-in-elm haha

                Did you check this: http://package.elm-lang.org/packages/eeue56/elm-xml/latest ?
                1. 2

                  Thanks. The initial commit is from this year, so I don’t think it existed when I last looked. Will try it.

          1. 6

            This is a good start! I imagine they might go into it later in the series but RemoteData is super useful here: http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html

            1. 1

              Hey Brian, This is awesome! I will try to talk about that later! And Yeah, this was a good starting point about getting data from APIs, in this case, just JSON ;)

            1. 7

              A very nice post on Elm coding in general! Alternate title: Parsing JSON in a strongly typed language means writing the structure of that json in said language. Its a common challenge and I’ve recenly come across some helpful sites to take a blob of json and write the code that matches its structure.

              Elm = http://json2elm.com/ Go = https://mholt.github.io/json-to-go/

              1. 1

                Hey man, I really liked your link! Thanks for sharing it!

              1. 1

                I think the article could gain to be augmented with links to the appropriate documentation, for example save vs save! as seen here: http://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-save

                If I recall correctly, this isn’t a new behavior; I believe most of the “!”-ended methods in Ruby idiomatically do “destructive” things to the underlying object instead of working on copies (see “String.reverse” vs “String.reverse!”). Well done, otherwise.

                1. 3

                  The sad part of the save! name is that the bang doesn’t indicate destructive behavior, it means “this method will raise an error if the save fails”, which is different semantics from the idiomatic Ruby meaning. Another “fun” Rails quirk.

                  1. 2

                    I wouldn’t call it a quirk; it’s fairly consistent with the meaning of bang according to Matz : https://www.ruby-forum.com/topic/176830#773946

                    The bang (!) does not mean “destructive” nor lack of it mean non destructive either. The bang sign means “the bang version is more dangerous than its non bang counterpart; handle with care”. Since Ruby has a lot of “destructive” methods, if bang signs follow your opinion, every Ruby program would be full of bangs, thus ugly.

                    1. 1

                      At my job we end up treating the bang version of save with less care, because we know it will raise an error if things go wrong and not silently propagate a bug.

                    2. 1

                      Agreed. I expressed myself poorly; I meant to suggest that someone familiar with Ruby would surely have some form of alarm bell ringed in his mind if he saw “!” at the end of a method name; it’s a bit sad that it potentially raises errors, though.

                    3. 2

                      I’ve just added the links. :)