profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/chrismccord/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

chrismccord/atlas 212

Object Relational Mapper for Elixir

chrismccord/dot_emacs 91

evil-mode

chrismccord/ex_copter 9

Elixir client for the Parrot AR 2.0 Quadcopter

chrismccord/bclose.vim 7

Delete a buffer without closing the window

chrismccord/blinky_presence 7

Phoenix Presence with Nerves example

issue commentphoenixframework/phoenix_live_view

Allow MFArgs for on_mount hooks

Further thinking about this, I think @mcrumm proposal is the most straight forward option. I think the {M, F, Keyword.t()} will absolutely trip folks up with match errors, I also think we should avoid {M, Keyword.t()} in favor of multiple functions, so MFA is the most straight forward on what module + function + args means to folks. We could even raise if we detect a keyword and instruct what the user needs to change. We could also rewrite the keyword and wrap as a single list argument, but I think special casing also can be confusing.

mcrumm

comment created time in 2 days

issue commentphoenixframework/phoenix_live_view

Allow MFArgs for on_mount hooks

We need it if you want to pass any thing to the callback, such as a role for your authentication code. Var args could of course work, but I think the syntax will be unusual compared to the tuple form folks are used to when wanting to pass keyword options, which are pretty ubiquitous. For example the following could would be allowed under the current proposal:

on_mount {UserAuth, :authenticate_mount, role: :admin, key: :user_id}

But it would be invoked as UserAuth.authenticate_mount(params, session, socket, {role: :admin}, {key: :user_id})) which I think would be surprising to many folks.

mcrumm

comment created time in 2 days

issue commentphoenixframework/phoenix_live_view

Allow MFArgs for on_mount hooks

errr, we'd support the following:

on_mount MyModule
on_mount {MyModule, :func}
on_mount {MyModule, :func, foo: :bar}
mcrumm

comment created time in 2 days

issue commentphoenixframework/phoenix_live_view

Allow MFArgs for on_mount hooks

@mcrumm to be clear, we would only support {M, F, Keyword.t} so there is no single callback per module. We could remap {M, :f} to {M, :f, []} as well, or rely on the user to opts \\ [] it.

mcrumm

comment created time in 2 days

issue commentphoenixframework/phoenix_live_view

Allow MFArgs for on_mount hooks

@dvic We still support on_mount MyModule so I think the only thing we are missing is init, which I'm not convinced we need in this case?

@mcrumm I also think keyword list options would be preferable over var args since it mirrors a lot of what we see, such as child specs, which resolves the point that @schrockwell raised.

mcrumm

comment created time in 2 days

issue openedphoenixframework/phoenix_live_view

Rename lifecycle default mount callback to on_mount

As discussed with @crumm, we should rename the default mount callback to on_mount for lifecycle hooks declared with on_mount MyModule. Today the we call mount if no MF is provided, but this leads to overloading what kind of mount you're looking at in any given module. For example, imagine you use Phoenix.Component to define a group of function components. You may also define this module as a lifecycle hook. Seeing use Phoenix.Component then def mount/3 is eerily close to use Phoenix.LiveComponent and can be confusing what it is this module is responsible for. I propose for 0.17 we rename the default function to on_mount to better signal the purpose. Thoughts // @josevalim @jeregrine

created time in 3 days

issue commentphoenixframework/phoenix

Allow MFArgs for on_mount hooks

If you passed a keyword list with Crumm's proposal, it would just work with your code example :)

mcrumm

comment created time in 3 days

issue closedphoenixframework/phoenix_html

Proposal: add add/remove buttons to make inputs_for dynamic

Proposal: add add/remove buttons to make inputs_for dynamic

Summary

Hi.

I was refactoring some old code, and noticed that the implementation for inputs_for/4 didn't allow for a dynamic remove and addition of items on the collection, which is understandable, as such implementation would require some JavaScript code and some added elements to make it work.

After trying some other external libraries and implementing the function on my own, I thought that maybe other people can make use of this functionality, as it's a fairly common on other form building libraries for other languages.

Background

If you go through the elixir forum, you can find people having related problems, there aren't too many people requesting this functionality, but I still think it would be a great addition.

Also, all current libraries that implement this function have some undesirable quirks that can cause some headache or are unmaintained (I will probably reference them also as an inspiration on the pull request, if accepted).

Proposal

I already have an implementation of such feature coded. It's fairly self-contained and needs only a few lines of code, if implemented directly on the phoenix_html it will have even fewer lines, currently there are around 40 JavaScript lines, 25 elixir lines and 20 eex lines.

It basically creates a template tag that contains the actual code for the "nested form", and each time the user clicks on the add button, it calculates the current last index and inserts a new instance of the "form" replacing the old index.

The deletion of items on the list is based on a wrapped div outside each "nested form", and removes the entire element.

Conclusion

If my proposal is accepted, I can port my code to the official code and open a pull request.

Related issues

Looking through old issues, there seems to be a "issue" against a implementation of a type of array input, which is fairly related, to the feature I'm proposing.

closed time in 5 days

ogabriel

issue commentphoenixframework/phoenix_html

Proposal: add add/remove buttons to make inputs_for dynamic

This sounds like a great external library or blog post so other folks can take advantage of your work. We don't intend to expand the very limited javascript capabilities of phoenix_html and dynamic features will rather be developed on the LIveView side. That said, your solution for non LiveView users sounds like a great option for folks. Thanks!

ogabriel

comment created time in 5 days

pull request commentphoenixframework/phoenix_live_view

Fix generated self close tag

❤️❤️❤️🐥🔥

msaraiva

comment created time in 11 days

push eventphoenixframework/phoenix_live_view

Marlus Saraiva

commit sha e9574999d2be5c4eb974dfbe7aa108d0b67a8483

Fix generated self close tag (#1616)

view details

push time in 11 days

issue closedphoenixframework/phoenix_live_view

HTMLEngine produces invalid HTML for self-closing tags

Environment

  • Elixir version (elixir -v): 1.12.2
  • Phoenix version (mix deps): 1.5.12
  • Phoenix LiveView version (mix deps): 0.16.1
  • Operating system: OSX
  • Browsers you attempted to reproduce this bug on (the more the merrier): Chrome
  • Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: Yes

Actual behavior

When I have a tag like <div /> (with attributes, but doesn't matter here), the browser doesn't close the div tag. This causes elements to get put as children of the div, even though they are not defined as children.

Expected behavior

A self-closing HTML tag should either raise (invalid HTML) or close via the correct tag. So <div /> should turn into <div></div>.

If developers are expecting heex to feel like JSX (for better or worse), then the tag should become properly closed and not raised.

closed time in 11 days

sb8244

create barnchphoenixframework/phoenix_pubsub

branch : cm-dirty-list

created branch time in 11 days

pull request commentphoenixframework/phoenix_live_view

Relax html tag validation

❤️❤️❤️🐥🔥

msaraiva

comment created time in 11 days

push eventphoenixframework/phoenix_live_view

Marlus Saraiva

commit sha 34a434c247669da567e176bec3c04e62a8e3b607

Relax html tag validation (#1615)

view details

push time in 11 days

PR merged phoenixframework/phoenix_live_view

Relax html tag validation

Otherwise the tokenizer emits a warning for things like:

<svg>
  ...
    <linearGradient ...>
      ...
    </linearGradient>
  ...
</svg>
+1 -34

0 comment

2 changed files

msaraiva

pr closed time in 11 days

delete branch phoenixframework/phoenix

delete branch : jv-no-secret-key-base-fallback

delete time in 12 days

pull request commentphoenixframework/phoenix

No secret key base fallback

❤️❤️❤️🐥🔥

josevalim

comment created time in 12 days

push eventphoenixframework/phoenix

José Valim

commit sha cf34912543b2ed776d3f74695957f792ed46c878

No secret key base fallback, closes #4465 (#4468)

view details

push time in 12 days

issue closedphoenixframework/phoenix

`secret_key_base`, `signing_salt` in version control considered harmful

<!--

Precheck

  • For general discussions and support, use Stack Overflow or the Elixir Forum
  • For proposing and discussing new features, start a thread on the Phoenix Core mailing list
  • For bugs, do a quick search and make sure the bug has not yet been reported
  • Ensure that this issue is related to the Phoenix library and not one of the dependencies listed in mix.exs (Ecto, Plug, etc.)
  • All checked? Be nice and have fun! -->

Howdy Phoenix!

I was in the middle of writing a tutorial about implementing OAuth and session persistence in a Phoenix application, when I noticed something a little ... silly, I think is the right word for it.

I won't beat around the bush, as this issue ticket's title has already gotten down to brass tacks: config/config.exs and /lib/app_web/endpoint.ex are terrible places to make the default homes for AppWeb.Endpoint's :secret_key_base and :signing_salt! There's all kinds of opportunity for these keys to unwittingly enter the codebase, and having it be in there as early as the very first git commit. I didn't even realize I had committed secret_key_base to my own repo until I'd already made 30 commits on main!

I think the simplest way to go about fixing this issue is to migrate the secret values into /config/dev.secret.exs. Here's how I've implemented it in my own project:

# /config/config.exs
import Config

env = config_env()

...

# Import environment specific config. This must remain at the bottom
# of this file so it overrides the configuration defined above.
import_config "#{env}.exs"

with secret_config <- "#{env}.secret.exs",
  true <- File.exists?("#{__DIR__}/#{secret_config}"),
  do: import_config(secret_config)

Then, in .gitignore:

...
# anything with `.secret` as an extension
*.secret.*
*.secret
...

The ignore rule used to be /config/*.secret.exs, but then I thought, why limit the scope of an extension I anticipate only using for files I want to keep out of version control?


I don't know how important this ranks on the Phoenix team's priorities, but it just feels like an easy thing to correct that'll have reasonable payoff in the short and long-term. Not saying that any other framework is the thing Elixir should strive to become, but it's a strong enough security concern that Rails generates a /config/master.key inside of new projects, and immediately adds it to the project's .gitignore. It seems reasonable to have similar defaults within new Phoenix apps. Plus, since Elixir releases only contain compiled .beam files, {env}.secret.exs config files come with a much greater degree of security, as their source code is fundamentally never needed for an app after the build phase.

Anyway, that's all I got this time. Phoenix 1.6.0 is pretty spiffy so far! I'd already split out Sass's behavior from Webpack in 1.5, and am so happy to finally have an uncomplicated asset pipeline with it and esbuild.

closed time in 12 days

thepeoplesbourgeois

push eventphoenixframework/phoenix_live_view

Chris McCord

commit sha 2f4e3ef3f056c452bbaab4d8607bc4167da188ea

Update guides/client/js-interop.md

view details

push time in 12 days

Pull request review commentphoenixframework/phoenix_live_view

Document how to trigger phx-events from JavaScript

 In the case of an `"element"` page loading event, the info will contain a `"target"` key containing the DOM element which triggered the page loading state. +## Triggering phx events with JavaScript++Often it is desirable to trigger an event on a DOM element without explicit
Often it is desirable to trigger an event on a form element without explicit
Gazler

comment created time in 12 days

PullRequestReviewEvent

push eventphoenixframework/phoenix_live_view

Chris McCord

commit sha 8b1ae212c77c8bf20ea741de39c5470f530b52eb

Update guides/client/js-interop.md

view details

push time in 12 days

Pull request review commentphoenixframework/phoenix_live_view

Document how to trigger phx-events from JavaScript

 In the case of an `"element"` page loading event, the info will contain a `"target"` key containing the DOM element which triggered the page loading state. +## Triggering phx events with JavaScript
## Triggering phx form events with JavaScript
Gazler

comment created time in 12 days

PullRequestReviewEvent

pull request commentphoenixframework/phoenix

Sync Diff function in Elixir just like JS

This would be a great addition and something I've recently been thinking about, so perfect timing :)

Have you thought about what the interface would look like to allow the user to hook into joins and leaves, similar to the JavaScript API? For example, for LiveView you likely want some kind of reduce operation that allows you to handle each join and leave of the sync_diff operation and accumulate specific socket state or send_update to a child component. I need to think a bit more about what an API could look like and play with some pseudo code, but will need to wait until next week. I'd love to hear your ideas since you're in this space! Thanks!

dewetblomerus

comment created time in 15 days