Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[suggestion] Handling urls and constants in Elm #106

Open
mrapacz opened this issue Sep 4, 2017 · 0 comments
Open

[suggestion] Handling urls and constants in Elm #106

mrapacz opened this issue Sep 4, 2017 · 0 comments

Comments

@mrapacz
Copy link
Collaborator

mrapacz commented Sep 4, 2017

Type

Question

Current behaviour
So far we didn't need any special way to handle e.g. image urls in our Elm app, because we could hardcode it in Constants.elm. Right now, the urls depend on the environment, so we need to change our functions accordingly:

before:
hostname : String
hostname =
    "http://localhost:4000/"

now: 
host : Location -> String
host location =
    location.hostname // whatever

If we were to evaluate the urls lazily (exactly when we need them), that would actually mean that we need to pass Location to our View (which doesn't seem very comfortable). My suggestion here is to approach it in another way:

Let's say we're adding an inbox page that would display messages from other players.

  1. We would create a special type that would represent the record with all the data needed for this module's Update, View etc. Let's call this type inboxDataType.
  2. We would add this type as a new part of our general Model
  3. Once initializing the whole model, we would just pass the location once and then save all the urls in this module's record
  4. Now we would only need to pass our instance of inboxDataType to the Update/View functions of this module and we could take already evaluated urls without the need of computing them again (no need to pass Location around).

Motivation / use case

  • no need to pass the Location around
  • possible improvement in app's speed (no need to compute the url with every call to update/view)
  • possible downside -> more memory consumed

@pmrukot @jtkpiotr let me know if this approach seems reasonable for you. I think we could use this in #56.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant