weaverryan
Repos
246
Followers
1718
Following
40

Events

moving public method above private methods

Compiling last changes to decorator

Created at 1 hour ago

Compiling minor tweaks from builder section

Created at 4 hours ago

Compiling tweaks to strategy pattern - created a todo for builder pattern

Created at 4 hours ago
add support for PostgreSQL

Adds support and fixes issues for PostgresSQL.

Should be merged before https://github.com/SymfonyCasts/messenger-monitor-bundle/pull/43

Created at 4 hours ago

add support for PostgreSQL

feature #45 add support for PostgreSQL (bendavies)

This PR was merged into the master branch.

Discussion

add support for PostgreSQL

Adds support and fixes issues for PostgresSQL.

Should be merged before https://github.com/SymfonyCasts/messenger-monitor-bundle/pull/43

Commits

e0168b6 add support for PostgreSQL

Created at 4 hours ago
add support for PostgreSQL

Thanks Ben!

Created at 4 hours ago
any plan for a new major release?

Ah, I think I understand. The idea behind this bundle was actually to purposefully put the small amount of "provider glue code" inside of this repository to make everyone's live easier. I think you're proposing a structure that would have the following libraries (using facebook as an example):

A) oauth2-client B) league/oauth2-facebook (the client provider for oauth2-client + Facebook) C) knpuniversity/oauth2-client-bundle D) some new oauth2-facebook-client which would be a "provider" to glue league/oauth2-facebook together with knpuniversity/oauth2-client-bundle

If that's accurate, I think it's more realistic to maintain one bundle (this one) that has all of that "glue code" inside of it. If we don't provide that glue code, in reality, people will not create entire separate libraries to implement that part. If you mean that libraries like league/oauth2-facebook could add 1 class of glue code, again, I don't think that will happen in practice: many libraries won't want Symfony-specific classes in their libraries.

Cheers!

Created at 7 hours ago
issue comment
[LiveComponent] Embeded stimulus controller in a live form not working on re-render

Hi @tdumalin!

Thanks for the reproducer! That was super helpful! This is definitely an area we want to make smoother, even if it's just via documentation.

In this case, when the Stimulus controller's connect() is called, it makes a number of changes to the HTML around your input: https://github.com/airblade/stimulus-datepicker/blob/b672a0da67f28520cd1fc7a3375f44632122a595/src/datepicker.js#L38-L41

When the component re-renders, we have 2 options:

A) We make sure to NOT overwrite these changes - i.e. we add data-live-ignore B) We overwrite the field, but then reinitialize the Stimulus controller.

As you guessed, (A) is definitely the first thing to try. I added it to the <div class="input-group mb-3" that's around the entire field and it worked fine. But you mentioned a LiveCollectionType? Have you tried adding data-live-ignore to this element in your real situation? What bad behavior does it cause?

For (B), what we can do is force LiveComponents to TOTALLY re-render the "date" field instead of just "modifying the things inside that changed". This will trigger the datepicker Stimulus controller to be removed and a totally new one to be added. To do this, you would give that same <div class="input-group mb-3" element a data-live-id attribute... but this attribute would need to CHANGE (to some new, unique value) each time you wanted this field to totally re-render. Currently, I'm not sure this is really an option, because you would need to make sure that the data-live-id ALWAYS changes (like, set it to a random value) so that it is always re-rendered.

Another interesting approach might be to combine the two - e.g. <div class="input-group" data-live-ignore data-live-id="foo" where you use data-live-ignore to fix the problem (solution A). But then, if, for some reason, you ever needed the field to totally re-render (maybe the value of this field was just changed on the server), you could change the data-live-id to some other value. However, currently, this doesn't work, as data-live-ignore tells the system to "never remove this element on re-render". But if this solution sounds useful for your situation, we can explore how to make it possible.

Cheers!

Created at 8 hours ago

[Vue] Add support for lazy-loading with Async Components

feature #482 [Vue] Add support for lazy-loading with Async Components (Kocal)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Vue] Add support for lazy-loading with Async Components

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #... | License | MIT

I was a bit surprised when trying the Symfony UX' Vue integration, to see all Vue components/controllers to be loaded to render at least only one controllers. This PR aims to reduce the bundle size and only load the required code and Vue controllers to render on the page.

To enable lazy-loading, add the 4th parameter "lazy" to require.context():

- registerVueControllerComponents(require.context('./vue/controllers', true, /\.vue$/));
+ registerVueControllerComponents(require.context('./vue/controllers', true, /\.vue$/, "lazy"));

Note: the sync-loading still works

Real life example

Given 6 really simple Vue controllers which all look the same:

If I render only two of them on a single page:

Before

You can see the app.js is about 4.8 kB, it contains all of the 6 Vue controllers.

After

You can see the app.js is now about 3.4 kB, and two more files have been lazy-loaded (our two Vue controllers rendered on the page).

On a real project, with a lot of Vue controllers, the difference would be very significative. I will try to post some results when migrating our main project at work.


Note: ~I still have to add tests and update the documentation.~ done

Commits

8fa08d0 [Vue] Add support for lazy-loading with Async Components

WIP heavy refactoring to Component

Initial "hook" system used to reset model field after re-render

Adding a 2nd hook to handle window unloaded

reinit polling after re-render

Adding Component proxy

fixing some tests

Refactoring loading to a hook

fixing tests

rearranging

Refactoring polling to a separate class

removing finished TODO

initial component child tracking/setup

Removing originalData - new child logic will not need this

client-side implementation of differentiating between data & props

This will be needed later for child component handling, where the server will send down a list of updated "props" only, and the client side will need to update the props of a component, without changing the "data" that may have already been altered by the user.

Adding the fingerprint to the system, but not using it yet

Sending childrenFingerprints data to server on Ajax call

Starting new child tests

starting test case and implementation for morphdom child rendering

Fixing testing bug that caused tough-to-read fetch-mock errors

Adding complex test for child re-rendering + final implementation

Created at 8 hours ago
pull request closed
[Vue] Add support for lazy-loading with Async Components

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #... | License | MIT

I was a bit surprised when trying the Symfony UX' Vue integration, to see all Vue components/controllers to be loaded to render at least only one controllers. This PR aims to reduce the bundle size and only load the required code and Vue controllers to render on the page.

To enable lazy-loading, add the 4th parameter "lazy" to require.context():

- registerVueControllerComponents(require.context('./vue/controllers', true, /\.vue$/));
+ registerVueControllerComponents(require.context('./vue/controllers', true, /\.vue$/, "lazy"));

Note: the sync-loading still works

Real life example

Given 6 really simple Vue controllers which all look the same:

If I render only two of them on a single page:

Before

You can see the app.js is about 4.8 kB, it contains all of the 6 Vue controllers.

After

You can see the app.js is now about 3.4 kB, and two more files have been lazy-loaded (our two Vue controllers rendered on the page).

On a real project, with a lot of Vue controllers, the difference would be very significative. I will try to post some results when migrating our main project at work.


Note: ~I still have to add tests and update the documentation.~ done

Created at 8 hours ago
push

[Vue] Add support for lazy-loading with Async Components

feature #482 [Vue] Add support for lazy-loading with Async Components (Kocal)

This PR was squashed before being merged into the 2.x branch.

Discussion

[Vue] Add support for lazy-loading with Async Components

| Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | Tickets | Fix #... | License | MIT

I was a bit surprised when trying the Symfony UX' Vue integration, to see all Vue components/controllers to be loaded to render at least only one controllers. This PR aims to reduce the bundle size and only load the required code and Vue controllers to render on the page.

To enable lazy-loading, add the 4th parameter "lazy" to require.context():

- registerVueControllerComponents(require.context('./vue/controllers', true, /\.vue$/));
+ registerVueControllerComponents(require.context('./vue/controllers', true, /\.vue$/, "lazy"));

Note: the sync-loading still works

Real life example

Given 6 really simple Vue controllers which all look the same:

If I render only two of them on a single page:

Before

You can see the app.js is about 4.8 kB, it contains all of the 6 Vue controllers.

After

You can see the app.js is now about 3.4 kB, and two more files have been lazy-loaded (our two Vue controllers rendered on the page).

On a real project, with a lot of Vue controllers, the difference would be very significative. I will try to post some results when migrating our main project at work.


Note: ~I still have to add tests and update the documentation.~ done

Commits

8fa08d0 [Vue] Add support for lazy-loading with Async Components

Created at 8 hours ago
issue comment
[Vue] Add support for lazy-loading with Async Components

Thanks Hugo!

Created at 8 hours ago

[Vue] Add support for lazy-loading with Async Components

Created at 8 hours ago
create branch
weaverryan create branch component-object
Created at 8 hours ago
issue comment
Introduce UX React component

Could you open a separate issue? We COULD do this - in the Stimulus controller, we could read the innerHTML of the element and make it available as props.children via dangerouslyInnerHtml (we would make this opt-in - so we would need some sort of new option to enable this).

Created at 1 day ago
any plan for a new major release?

Hi!

No immediate plans for a new major - but just because we haven't seen any need yet.

to not keep all providers into the code base:

You think some should be removed? What would be the motivation for that?

provide an interface and each provider implement that!

Can you explain this a bit further? I'm not familiar with what oauth2-client does for this :).

Cheers!

Created at 1 day ago
pull request closed
inline createForm -> HandleRequest
Created at 1 day ago
issue comment
inline createForm -> HandleRequest

I don't feel too strongly either way. But Maker should generate code like the docs - so a change like this should be proposed there first :).

Cheers!

Created at 1 day ago
issue comment
Fix error with eslint due to variable initialization before checking, eslint was set

Hi there!

What is the exact error that you get when building for production? And was it necessary to move all of those require statements? Or is there just 1 specifically that fixes the problem.

Your situation makes sense... but I am having a hard time seeing why any of those require statements would cause a problem. But seeing the error might help clarify :).

Cheers!

Created at 1 day ago
issue comment
[Symfony UX React] component not rendering

Hmm, it sounds like your browser might be very eagerly holding onto your cached JavaScript. In webpack.config.js, change this line - https://github.com/symfony/recipes/blob/85dc7cd2f0049f9a86a6d020691ea217561f33e5/symfony/webpack-encore-bundle/1.10/webpack.config.js#L46 - simply to .enableVersioning(). That will enabled versioned filenames even in dev (no real downside to this) and should help if the problem is browser caching.

Cheers!

Created at 1 day ago
issue comment
[Live Component] Error exeption on live component when HTMLElement is a Commit

Definitely a bug - excellent catch! We can certainly fix this to not "trip over" the fact that the first child is a comment.

and return some event from live-component.js that we could catch and serve with our own script.

To be clear: you would like a new event so you could handle Ajax errors yourself? For example, a live:response-error where we pass the html and response to you? It would go right before this line, if I understand you correctly: https://github.com/symfony/ux/blob/47be741969c239bf7d73a7a0644cc8e8ce8adc18/src/LiveComponent/assets/src/live_controller.ts#L477

Created at 1 day ago
issue comment
[Vue] Add support for lazy-loading with Async Components

@Kocal I think you're right - but I think that will be solved by #461

Created at 1 day ago