Ruby on Rails Saturday, February 29, 2020

Great opportunity to join a team who are making a real difference to peoples lives.

SH:24 is an innovative and multi-award winning health tech company, working in partnership with the NHS to deliver online sexual and reproductive services across the UK, 24:7.

We are a multi-brand non-profit, with an appetite for social good, innovation and sustainable growth. We strive for continuous improvement and believe that employers need to invest in their staff and ensure they are always learning and developing their skills.

We are currently a team 8 developers, all committed to TDD. 

We're looking for at least seniors to join the team.

More about us 
We have a flat, transparent structure where everyone is encouraged to speak up and have their say.

We foster  a positive, diverse, and inclusive  company culture. We always strive to adapt our culture to make SH:24 a more welcoming place to work.

We promote self-management, offering service users a portfolio of clinically assured, discreet and easy to access services which would traditionally be delivered in NHS clinics.

We offer:
- Unrivalled specialist clinical advice and support
- Interactive sexual health risk assessments with linked health promotion advice
- STI home test kits 
- Treatments
- Access to a range of contraception

Our users move seamlessly between digital and physical services, with clinical excellence ensured through partnership with NHS specialist sexual health services.

Our objective is to improve access to sexual health services through a more holistic, user centred service. The service is designed to be flexible around the needs of users, encouraging greater autonomy, both in making decisions about their care and in navigating their preferred route through services.

More and how to apply here.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/017380ef-2ab2-4ca2-87bd-4e6fce825aed%40googlegroups.com.

Ruby on Rails Thursday, February 27, 2020



On Thursday, February 20, 2020 at 7:35:54 AM UTC-5, SM Ehsan wrote:
Hello
I a trying to add froala WYSIWYG editor to my rails 6 project.
but i am unable to add this.
can any one please tell me how can i add froala WYSIWYG editor to my project?

Thank you

rails 6 includes Trix wysiwyg editor, its easy to setup

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b4eaafa5-0548-419e-80fb-3fed6fded93f%40googlegroups.com.

Ruby on Rails

Hi All,

 

Greeting's from Benvia!!

 

We have an urgent opening for Sr. Ruby On Rails Developer at San Francisco, CA

 

Title: Sr. Ruby On Rails Developer

Location: San Francisco, CA

Duration: Long Term

 

Job Description

Gather and analyse requirements, design and develop software applications.

Have designed & architecture enterprise solution involving various technologies.

Lead small and mid-size project teams to perform a variety of day to day development activities. Onsite and Offshore

Conduct code reviews of completed technical artifacts.

Provide ongoing system support by maintaining and enhancing existing software applications. Handle multiple tasks and work on multiple projects.

8+ years' experience as a developer, designing and implementing large-scale enterprise applications

Experience with Ruby on Rails is must.

5+ years of hands on experience working with JAVA/J2EE technologies.

In-depth knowledge of publishing as well consuming of Web Services, REST Services

Strong understanding of Agile/Scrum principles to assist in the evangelism of processes

Understanding of continuous delivery tools and best practices

Understanding of quality assurance best practices including test automation

 

Education

Bachelor's degree in Computer Science, Information Systems, Engineering, Computer applications or related field



Regards

 

Salman
Description: 6052aba3c72caed69fa2f2dbae1cb373

Work: +17329174883

Benvia

Email: abdul.salman@benvia.com

www.benvia.com


--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/42d56a9e-1bd6-4249-94d7-48229f78101e%40googlegroups.com.

Ruby on Rails Sunday, February 23, 2020

Google
Estamos melhorando nossos Termos de Serviço para que eles sejam mais fáceis de entender. As mudanças entrarão em vigor em 31 de março de 2020 e não terão nenhum impacto na maneira como você usa os serviços do Google.
Para mais detalhes, fornecemos um resumo das principais mudanças e respondemos às Perguntas frequentes. Na próxima vez que você acessar o Google, poderá revisar e aceitar os novos Termos. Em resumo, isto é o que essa atualização significa para você:
Entendimento facilitado: ainda que se trate de um documento jurídico, fizemos o melhor possível para facilitar o entendimento dos nossos Termos, incluindo links para informações úteis e fornecendo definições.
Comunicação melhorada: explicamos claramente quando faremos mudanças nos nossos serviços, como adição e remoção de um recurso, e quando o acesso de um usuário será restringido ou encerrado. Além disso, faremos o possível para notificar você quando uma mudança impactar negativamente sua experiência nos nossos serviços. Também descrevemos como os pedidos de divulgação de dados são respondidos, por exemplo, solicitações de agências governamentais.
Inclusão do Google Chrome, Chrome OS e Drive nos Termos: agora, nossos Termos melhorados se aplicam ao Google Chrome, Chrome OS e Drive. Esses serviços também possuem termos e políticas específicos para ajudar você a entender o que é exclusivo de cada um deles.
Nenhuma mudança na nossa Política de Privacidade: não estamos mudando nada na Política de Privacidade do Google e não mudamos a forma como tratamos suas informações. Você pode acessar sua Conta do Google sempre que quiser para revisar suas configurações de privacidade e gerenciar como seus dados são utilizados.
Se você for responsável por uma criança abaixo da idade necessária para gerenciar a própria Conta do Google e você usar o Family Link para gerenciar o uso dos serviços do Google, observe que ao aceitar os novos Termos, você também os aceita em nome dessa criança, então recomendamos conversar com ela sobre as mudanças.
Além disso, caso você não concorde com os novos Termos e o que é esperado de ambas as partes ao usar os serviços, veja mais informações sobre suas opções nas nossas Perguntas frequentes.
Agradecemos por usar os serviços do Google.
Sua Equipe do Google

Ruby on Rails Thursday, February 20, 2020

What have ou tried? There's a gem but I think it's only intended to be used with Sprockets and not Webpacker, I would start with the readme https://github.com/froala/wysiwyg-editor using the npm package and importing froala as a module https://github.com/froala/wysiwyg-editor#load-froala-editor-as-a-transpiled-es6umd-module

El jue., 20 feb. 2020 a las 11:44, San Ji (<sarun101@gmail.com>) escribió:
Hard to pass this thread without mentioning Action Text; It is the Rails way of WYSIWYG editor and shipped with Rails 6.

If you know about it already, NVM.
As for the question itself, I never heard about Froala until today.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/f6881350-8dc3-4c6e-88d0-22729f1163d0%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAPS3bcDJYbXNs7Z9g%3Dkq0vcxCHwEiaGzahsJNbinqEK2hy-zLA%40mail.gmail.com.

Ruby on Rails

For your information, the context of my previous post is focused on form_with, the method in the discussion.

But, for broader sense, Basecamp and DHH are great and generous companion to be in the same community. You can't find community like this somewhere else.

However, we all eventually grow up from the Rails way.
You are frustrating with Turbolinks, et al, these are normal.
Me too, have the same experience, my project don't even use Active Record, for me it is a pain, and every design based on ER diagram is usually subpar IMO.

However, I won't give up on Rails, it is so far beyond other community from my point of view. After all Rails is just a bunch of libraries, if you don't like some, just ignore it, the benefit from the community is far exceeding it down side.

And you too, should see it already, or you won't stick to it this long.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/1292fc26-7877-49e3-b006-63162a5490cc%40googlegroups.com.

Ruby on Rails

Hard to pass this thread without mentioning Action Text; It is the Rails way of WYSIWYG editor and shipped with Rails 6.

If you know about it already, NVM.
As for the question itself, I never heard about Froala until today.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/f6881350-8dc3-4c6e-88d0-22729f1163d0%40googlegroups.com.

Ruby on Rails

Hello
I a trying to add froala WYSIWYG editor to my rails 6 project.
but i am unable to add this.
can any one please tell me how can i add froala WYSIWYG editor to my project?

Thank you

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/dac62a27-4744-4606-87c7-63c49d163167%40googlegroups.com.

Ruby on Rails Wednesday, February 19, 2020


I'm not suggesting any breaking changes at all. 

I've been using Rails since Rails version 2 so I don't know what you mean "like that from the beginning"

In the beginning, DHH said things would "just work" and, as a community we would value convention over configuration. 


As far as using ActiveModel with the form_with, I don't think that's relevant, it wouldn't make any difference as to behavior. 

All I'm suggesting is that Turbolinks is too complicated and should be OFF by default, like a lot of other things, so that it could be opted-into by the dev instead of forced upon us by the framework.





On Tuesday, February 18, 2020 at 1:41:03 PM UTC-5, San Ji wrote:
I don't think you can blame Rails 6 for that. It is a weird default, but it is like that from the very beginning.
I never use the method, so, I guess, it can be considered as somewhat obscure. It seems to appear in Rails version 5.1 and no change since.
Normally, I would use ActiveModel for a local form. Just in case you don't know, ActiveModel can also be used independently from ActiveRecord.

This is the earliest docs I found.
https://api.rubyonrails.org/v5.1/classes/ActionView/Helpers/FormHelper.html#method-i-form_with

Guess someone already complained, but it is too late; there is no good reason to introduces breaking changes for a better default.
Also, in a sense, this can be the better default, since ActiveModel is there for you to build a form for the same app.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/24f5f9ba-0d91-4279-bf10-841c06a2463a%40googlegroups.com.

Ruby on Rails

Let me try again on a new Rails app and confirm that I am right.… if what YOU say is correct then I missed something when debugging and it is my bad. 
Will revert on this

On Tuesday, February 18, 2020 at 1:41:02 PM UTC-5, Ariel Juodziukynas wrote:
I understand your complain, what I'm saying is that I have some rails 6 projects using form_for remote and form_with and I didn't have to bind to the ajax events. rails-ujs and jquery_ujs both expect you to render a view with .js format and both libraries executes your response's javascript.

Are you rendering a js view when you process the unsubscribe action? what does you action do? what do you respond to the user from your server? you have to tell rails what to do when you submit the form, how are you telling rails what to do?

El mar., 18 feb. 2020 a las 14:46, Momeas Interactive (<te...@datatravels.com>) escribió:

Yes, I was discussing this in the Slack channel yesterday in the #coding room

You're right that Rails no longer installs JQUery by default, but lots of things just go ahead and encourage it anyway. (which Is fine and not what I'm complaining about)


This guide, for example, as I said above, encourages you to use jQUery to add Ajax events to your form submit:


You could of course not use jQuery and do it another way, except that rails-ujs, which is really the problem here, expect you not to.

Right at the top of the https://github.com/rails/jquery-ujs/wiki/ajax docs it says that the UJS events are emitted through jQuery.

So I realize that UJS is also at play here, and neither UJS nor jQUery are my complaints. 

My complaint is that this obscure non-intuitive part of Rails is required to do something basic-- like submit a form-- and that Rails 6 has too much configuration over convention. 

These days when I install Rails 6 all I do is configuration, configuration, configuration (and fighting with these obscure parts of Rails to configure it some more) 
my code just looks like this:


- if @unsubscribe
  = form_with url: '/unsubscribe' do |f|
    = f.hidden_field :email, value: @unsubscribe.email
    = f.hidden_field :nonce, value: @unsubscribe.nonce

    You are confirming that you want to unsubscribe:
    %br
    %br
    = f.text_field :email, disabled: true, value: @unsubscribe.email
    %br
    %br
    = f.submit 'Unsubscribe'


When I do this, the form is submitted as Javascript (JS). if I add local: true then the form is submitted as HTML. 

This is not a bug, it is a complaint. 

the default behavior (to submit using JS) shouldn't leave my app in a non-working buggy state (nothing happens unless you bind an event to the Ajax event). that's the complaint. 

-Jason





On Tuesday, February 18, 2020 at 12:27:26 PM UTC-5, Ariel Juodziukynas wrote:
And also (sorry for the multiple responses), you are showing jquery code, rails moved out of jquery a long time ago (I think docs are outdated though), something might be wrong with your setup.

El mar., 18 feb. 2020 a las 14:25, Ariel Juodziukynas (<arie...@gmail.com>) escribió:
Can you share some code to reproduce the problem? (a github repo with a simple rais app would be greate)

El mar., 18 feb. 2020 a las 14:24, Ariel Juodziukynas (<arie...@gmail.com>) escribió:
I have a few rails 6 projects and remote forms works out of the box with no event binding. Can you reproduce that problem with a clean rails app? maybe you have some other js messing up rails' ajax handers.

El mar., 18 feb. 2020 a las 14:22, Momeas Interactive (<te...@datatravels.com>) escribió:
Incorrect. You HAVE to bind your Ajax events, or else there is no functionality. (the page does not refresh and gives no user interaction). I do not think that expecting user interaction is an abnormal expectation in a modern web app.



On Sunday, February 16, 2020 at 5:39:20 PM UTC-5, Ariel Juodziukynas wrote:
It doesn't say you that you HAVE to bind all the ajax events. It explicitly says that you "probably" want to do that if you "probably" want to do something other than just submitting the form.

El dom., 16 feb. 2020 a las 17:53, Momeas Interactive (<te...@datatravels.com>) escribió:
it says here in the docs that for turobolinks that you now have to BIND ALL YOUR AJAX EVENTS  (!?!?) if you want your forms to submit correctly. 



"You probably don't want to just sit there with a filled out <form>, though. You probably want to do something upon a successful submission. To do that, bind to the ajax:success event. On failure, use ajax:error. Check it out:"

$(document).ready ->
  $("#new_article").on("ajax:success", (event) ->
    [data, status, xhr] = event.detail
    $("#new_article").append xhr.responseText
  ).on "ajax:error", (event) ->
    $("#new_article").append "<p>ERROR</p>"


basically… sitting there with a filled out form is exactly what happens if you just do a generic form_with and post it now in Rails 6 … literally, the user just sits there and nothing happens.

are you really supposed to bind all your turbolinks forms throughout your website like this? This seems totally nuts to me, and, kind of, not at all 'unobtrusive' … (I thought the whole point of 'unobtrusive' was to not have to write a lot of helper/glue/boiler plate code.)

it seems totally crazy to me that out-of-the-box Rails 6 installations can't do the most basic web function of submitting a form without the developer having to know about binding events of the Ajax calls. In the old days didn't this used to 'just work' out of the box?

anyone else have any thoughts on this and think Rails is moving in the wrong direction here? The main attraction of Rais is how easy it is to make so much functionality with little config and effort, and this area seems too basic to me to require this top-heavy approach that requires binding up Ajax events.

I think Rails 7 should move away from having turbolinks turned on by default — it's a good technology if you want to opt-in to it, but it's got so much configuration that it often just gets in the way for new Rails apps. It would be very easy to simply leave off Turbolinks in default Rails apps and then simply provide instructions for opting-in to it. (Like, active record session store and other things that used to be default and then were extracted out into separate opt-in gems.) 


Thoughts?

Jason





--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/511637f0-dec3-4bd1-9648-a823c140669b%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/39ae14f7-72e1-48c3-9d44-371a4e9a799f%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9021a944-10e2-4320-9c2f-b5b68743fb8e%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/e8b46fc5-8dea-4185-a282-3f61d80f5cbe%40googlegroups.com.

Ruby on Rails

Each worker runs on a process. When you run the "ps" command on linux you'll see a list of processes running on your system, you'll have as many delayed job processes as you have configured. Each of those processes run a delayed job worker.

El mié., 19 feb. 2020 a las 3:21, Shubham Thakur (<shubham.t@sodelsolutions.com>) escribió:
Hi, 

I am bit confused in rails delayed job

1) what is workers
2) what is process?
3) both workers and processes are same ???????

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/34a0c565-175e-4fa9-bc61-f2f8523c20a4%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAPS3bcAoL-ja5bkBRN%2B3hWEzRcMzbP9SLSCCkqo9i635KBQ0vQ%40mail.gmail.com.

Ruby on Rails Tuesday, February 18, 2020

https://github.com/zdennis/activerecord-import may be helpful to you, Shubham.

On Tue, 18 Feb 2020 at 22:21, Shubham Thakur <shubham.t@sodelsolutions.com> wrote:
Hi,

I have around 25000, records and I want to save it into database using rails delayed job.

but its taking around 45-50 min, can anyone suggest me how can I do it faster.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/314e9e42-4a64-42d1-bb34-5658ac24bfcd%40googlegroups.com.


--
If you wish to request my time, please do so using bit.ly/hd1AppointmentRequest.
Si vous voudrais faire connnaisance, allez a bit.ly/hd1AppointmentRequest.

Sent from my mobile device
Envoye de mon portable

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAP%2BbYWCxdvOVDLTrnSA1kKj_Ucx9NswS178-f4uJ6tC1oJAPkQ%40mail.gmail.com.

Ruby on Rails

Hi,

I have around 25000, records and I want to save it into database using rails delayed job.

but its taking around 45-50 min, can anyone suggest me how can I do it faster.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/314e9e42-4a64-42d1-bb34-5658ac24bfcd%40googlegroups.com.

Ruby on Rails

Hi, 

I am bit confused in rails delayed job

1) what is workers
2) what is process?
3) both workers and processes are same ???????

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/34a0c565-175e-4fa9-bc61-f2f8523c20a4%40googlegroups.com.

Ruby on Rails

I don't think you can blame Rails 6 for that. It is a weird default, but it is like that from the very beginning.
I never use the method, so, I guess, it can be considered as somewhat obscure. It seems to appear in Rails version 5.1 and no change since.
Normally, I would use ActiveModel for a local form. Just in case you don't know, ActiveModel can also be used independently from ActiveRecord.

This is the earliest docs I found.
https://api.rubyonrails.org/v5.1/classes/ActionView/Helpers/FormHelper.html#method-i-form_with

Guess someone already complained, but it is too late; there is no good reason to introduces breaking changes for a better default.
Also, in a sense, this can be the better default, since ActiveModel is there for you to build a form for the same app.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/3e340425-4707-456e-9f3c-4a1a6fa09bc8%40googlegroups.com.

Ruby on Rails

I understand your complain, what I'm saying is that I have some rails 6 projects using form_for remote and form_with and I didn't have to bind to the ajax events. rails-ujs and jquery_ujs both expect you to render a view with .js format and both libraries executes your response's javascript.

Are you rendering a js view when you process the unsubscribe action? what does you action do? what do you respond to the user from your server? you have to tell rails what to do when you submit the form, how are you telling rails what to do?

El mar., 18 feb. 2020 a las 14:46, Momeas Interactive (<tech@datatravels.com>) escribió:

Yes, I was discussing this in the Slack channel yesterday in the #coding room

You're right that Rails no longer installs JQUery by default, but lots of things just go ahead and encourage it anyway. (which Is fine and not what I'm complaining about)


This guide, for example, as I said above, encourages you to use jQUery to add Ajax events to your form submit:


You could of course not use jQuery and do it another way, except that rails-ujs, which is really the problem here, expect you not to.

Right at the top of the https://github.com/rails/jquery-ujs/wiki/ajax docs it says that the UJS events are emitted through jQuery.

So I realize that UJS is also at play here, and neither UJS nor jQUery are my complaints. 

My complaint is that this obscure non-intuitive part of Rails is required to do something basic-- like submit a form-- and that Rails 6 has too much configuration over convention. 

These days when I install Rails 6 all I do is configuration, configuration, configuration (and fighting with these obscure parts of Rails to configure it some more) 
my code just looks like this:


- if @unsubscribe
  = form_with url: '/unsubscribe' do |f|
    = f.hidden_field :email, value: @unsubscribe.email
    = f.hidden_field :nonce, value: @unsubscribe.nonce

    You are confirming that you want to unsubscribe:
    %br
    %br
    = f.text_field :email, disabled: true, value: @unsubscribe.email
    %br
    %br
    = f.submit 'Unsubscribe'


When I do this, the form is submitted as Javascript (JS). if I add local: true then the form is submitted as HTML. 

This is not a bug, it is a complaint. 

the default behavior (to submit using JS) shouldn't leave my app in a non-working buggy state (nothing happens unless you bind an event to the Ajax event). that's the complaint. 

-Jason





On Tuesday, February 18, 2020 at 12:27:26 PM UTC-5, Ariel Juodziukynas wrote:
And also (sorry for the multiple responses), you are showing jquery code, rails moved out of jquery a long time ago (I think docs are outdated though), something might be wrong with your setup.

El mar., 18 feb. 2020 a las 14:25, Ariel Juodziukynas (<arie...@gmail.com>) escribió:
Can you share some code to reproduce the problem? (a github repo with a simple rais app would be greate)

El mar., 18 feb. 2020 a las 14:24, Ariel Juodziukynas (<arie...@gmail.com>) escribió:
I have a few rails 6 projects and remote forms works out of the box with no event binding. Can you reproduce that problem with a clean rails app? maybe you have some other js messing up rails' ajax handers.

El mar., 18 feb. 2020 a las 14:22, Momeas Interactive (<te...@datatravels.com>) escribió:
Incorrect. You HAVE to bind your Ajax events, or else there is no functionality. (the page does not refresh and gives no user interaction). I do not think that expecting user interaction is an abnormal expectation in a modern web app.



On Sunday, February 16, 2020 at 5:39:20 PM UTC-5, Ariel Juodziukynas wrote:
It doesn't say you that you HAVE to bind all the ajax events. It explicitly says that you "probably" want to do that if you "probably" want to do something other than just submitting the form.

El dom., 16 feb. 2020 a las 17:53, Momeas Interactive (<te...@datatravels.com>) escribió:
it says here in the docs that for turobolinks that you now have to BIND ALL YOUR AJAX EVENTS  (!?!?) if you want your forms to submit correctly. 



"You probably don't want to just sit there with a filled out <form>, though. You probably want to do something upon a successful submission. To do that, bind to the ajax:success event. On failure, use ajax:error. Check it out:"

$(document).ready ->
  $("#new_article").on("ajax:success", (event) ->
    [data, status, xhr] = event.detail
    $("#new_article").append xhr.responseText
  ).on "ajax:error", (event) ->
    $("#new_article").append "<p>ERROR</p>"


basically… sitting there with a filled out form is exactly what happens if you just do a generic form_with and post it now in Rails 6 … literally, the user just sits there and nothing happens.

are you really supposed to bind all your turbolinks forms throughout your website like this? This seems totally nuts to me, and, kind of, not at all 'unobtrusive' … (I thought the whole point of 'unobtrusive' was to not have to write a lot of helper/glue/boiler plate code.)

it seems totally crazy to me that out-of-the-box Rails 6 installations can't do the most basic web function of submitting a form without the developer having to know about binding events of the Ajax calls. In the old days didn't this used to 'just work' out of the box?

anyone else have any thoughts on this and think Rails is moving in the wrong direction here? The main attraction of Rais is how easy it is to make so much functionality with little config and effort, and this area seems too basic to me to require this top-heavy approach that requires binding up Ajax events.

I think Rails 7 should move away from having turbolinks turned on by default — it's a good technology if you want to opt-in to it, but it's got so much configuration that it often just gets in the way for new Rails apps. It would be very easy to simply leave off Turbolinks in default Rails apps and then simply provide instructions for opting-in to it. (Like, active record session store and other things that used to be default and then were extracted out into separate opt-in gems.) 


Thoughts?

Jason





--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/511637f0-dec3-4bd1-9648-a823c140669b%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/39ae14f7-72e1-48c3-9d44-371a4e9a799f%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9021a944-10e2-4320-9c2f-b5b68743fb8e%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAPS3bcDGVMXcqquFt15RkjCjPrSqzUgNgk9nP65RDc0zX4GKwA%40mail.gmail.com.

Ruby on Rails



On Tuesday, February 18, 2020 at 6:59:15 PM UTC+1, Momeas Interactive wrote:
I don't think polymorphism in Rails can work that way 

did you try


`has_many :users_following, through: :active_relationships, source: :followable, source_type: "FollowableUser"`

`has_many :projects_following, through: :active_relationships, source: :followable, source_type: "FollowableProject"`



Yeah I guess that would work. I would need to change a lot in my code but yeah I could do that. It's too bad if you can't do it in Rails

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/b3df4b44-223e-42aa-a2d2-737a86cc09a9%40googlegroups.com.

Ruby on Rails

I don't think polymorphism in Rails can work that way 

did you try


`has_many :users_following, through: :active_relationships, source: :followable, source_type: "FollowableUser"`

`has_many :projects_following, through: :active_relationships, source: :followable, source_type: "FollowableProject"`




On Monday, February 10, 2020 at 5:45:41 AM UTC-5, UG wrote:
I am trying to setup a way for my `User` and `Project` model to both be followed through the same `Relationship` model.

I also want to be able to get all items the user has followed with this association:
`has_many :following, through: :active_relationships, source: :followable, source_type: "Followable"`


This way, the projects and users any user has followed can be called with `user.following`. In this case, `Followable` is the polymorphic object that is attributed to both users and projects. Unfortunately, it seems that I cannot set my source_type to a polymorphic object. Is there a way I can bypass this?

Many thanks


--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/0facc107-25e3-4eea-9bae-753e5488ed7e%40googlegroups.com.

Ruby on Rails

Fugee-


when you switch from css to scss, you need to rename application.css to application.scss and do the following:

stop using //= require

instead use @import always and from now on when using scss. Do not use //= require syntax anymore

this is explained in the "IMPORTANT NOTE" at the top of the sass-rails docs:



if you are trying to install Bootstrap, there are some bad tutorials on the internet. I think one of them tells you to put the bootstrap.scss into your application.js file. Don't do that.

instead backtrack on what you did and use webpack to install Bootstrap (this is NOT the same as the 'old way' which you could still do on a Rails 6 app), simple instructions here : https://gorails.com/forum/install-bootstrap-with-webpack-with-rails-6-beta

-jason








On Saturday, January 18, 2020 at 10:23:56 PM UTC-5, fugee ohu wrote:


On Saturday, January 18, 2020 at 11:11:11 AM UTC-5, Ariel Juodziukynas wrote:
"//= require ..." is Sprocket's syntax (most known as rails' assets pipeline), not webpacker's. If you really want to handle CSS assets with webpacker you should start by reading this https://github.com/rails/webpacker/blob/master/docs/css.md

El sáb., 18 ene. 2020 a las 4:00, fugee ohu (<fuge...@gmail.com>) escribió:
I have my stylesheet in app/javascript/stylesheets and need to include actiontext.scss in application.scss where both files are located in app/javascript/stylesheets but using
//= require actiontext has no effect, styling is still not being applied

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/58c1a214-6a7c-4b16-8e02-60a17cbb15d9%40googlegroups.com.

Nothing in there about loaders I'm trying to get actiontext.scss to load I have listed in app/javascripts/packs/application.js
import "../stylesheets/actiontext.scss"
but the styling's  not being applied

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/67ee24bd-88bd-4289-b865-bb0c77eea749%40googlegroups.com.

Ruby on Rails


Yes, I was discussing this in the Slack channel yesterday in the #coding room

You're right that Rails no longer installs JQUery by default, but lots of things just go ahead and encourage it anyway. (which Is fine and not what I'm complaining about)


This guide, for example, as I said above, encourages you to use jQUery to add Ajax events to your form submit:


You could of course not use jQuery and do it another way, except that rails-ujs, which is really the problem here, expect you not to.

Right at the top of the https://github.com/rails/jquery-ujs/wiki/ajax docs it says that the UJS events are emitted through jQuery.

So I realize that UJS is also at play here, and neither UJS nor jQUery are my complaints. 

My complaint is that this obscure non-intuitive part of Rails is required to do something basic-- like submit a form-- and that Rails 6 has too much configuration over convention. 

These days when I install Rails 6 all I do is configuration, configuration, configuration (and fighting with these obscure parts of Rails to configure it some more) 
my code just looks like this:


- if @unsubscribe
  = form_with url: '/unsubscribe' do |f|
    = f.hidden_field :email, value: @unsubscribe.email
    = f.hidden_field :nonce, value: @unsubscribe.nonce

    You are confirming that you want to unsubscribe:
    %br
    %br
    = f.text_field :email, disabled: true, value: @unsubscribe.email
    %br
    %br
    = f.submit 'Unsubscribe'


When I do this, the form is submitted as Javascript (JS). if I add local: true then the form is submitted as HTML. 

This is not a bug, it is a complaint. 

the default behavior (to submit using JS) shouldn't leave my app in a non-working buggy state (nothing happens unless you bind an event to the Ajax event). that's the complaint. 

-Jason





On Tuesday, February 18, 2020 at 12:27:26 PM UTC-5, Ariel Juodziukynas wrote:
And also (sorry for the multiple responses), you are showing jquery code, rails moved out of jquery a long time ago (I think docs are outdated though), something might be wrong with your setup.

El mar., 18 feb. 2020 a las 14:25, Ariel Juodziukynas (<arie...@gmail.com>) escribió:
Can you share some code to reproduce the problem? (a github repo with a simple rais app would be greate)

El mar., 18 feb. 2020 a las 14:24, Ariel Juodziukynas (<arie...@gmail.com>) escribió:
I have a few rails 6 projects and remote forms works out of the box with no event binding. Can you reproduce that problem with a clean rails app? maybe you have some other js messing up rails' ajax handers.

El mar., 18 feb. 2020 a las 14:22, Momeas Interactive (<te...@datatravels.com>) escribió:
Incorrect. You HAVE to bind your Ajax events, or else there is no functionality. (the page does not refresh and gives no user interaction). I do not think that expecting user interaction is an abnormal expectation in a modern web app.



On Sunday, February 16, 2020 at 5:39:20 PM UTC-5, Ariel Juodziukynas wrote:
It doesn't say you that you HAVE to bind all the ajax events. It explicitly says that you "probably" want to do that if you "probably" want to do something other than just submitting the form.

El dom., 16 feb. 2020 a las 17:53, Momeas Interactive (<te...@datatravels.com>) escribió:
it says here in the docs that for turobolinks that you now have to BIND ALL YOUR AJAX EVENTS  (!?!?) if you want your forms to submit correctly. 



"You probably don't want to just sit there with a filled out <form>, though. You probably want to do something upon a successful submission. To do that, bind to the ajax:success event. On failure, use ajax:error. Check it out:"

$(document).ready ->
  $("#new_article").on("ajax:success", (event) ->
    [data, status, xhr] = event.detail
    $("#new_article").append xhr.responseText
  ).on "ajax:error", (event) ->
    $("#new_article").append "<p>ERROR</p>"


basically… sitting there with a filled out form is exactly what happens if you just do a generic form_with and post it now in Rails 6 … literally, the user just sits there and nothing happens.

are you really supposed to bind all your turbolinks forms throughout your website like this? This seems totally nuts to me, and, kind of, not at all 'unobtrusive' … (I thought the whole point of 'unobtrusive' was to not have to write a lot of helper/glue/boiler plate code.)

it seems totally crazy to me that out-of-the-box Rails 6 installations can't do the most basic web function of submitting a form without the developer having to know about binding events of the Ajax calls. In the old days didn't this used to 'just work' out of the box?

anyone else have any thoughts on this and think Rails is moving in the wrong direction here? The main attraction of Rais is how easy it is to make so much functionality with little config and effort, and this area seems too basic to me to require this top-heavy approach that requires binding up Ajax events.

I think Rails 7 should move away from having turbolinks turned on by default — it's a good technology if you want to opt-in to it, but it's got so much configuration that it often just gets in the way for new Rails apps. It would be very easy to simply leave off Turbolinks in default Rails apps and then simply provide instructions for opting-in to it. (Like, active record session store and other things that used to be default and then were extracted out into separate opt-in gems.) 


Thoughts?

Jason





--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/511637f0-dec3-4bd1-9648-a823c140669b%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/39ae14f7-72e1-48c3-9d44-371a4e9a799f%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9021a944-10e2-4320-9c2f-b5b68743fb8e%40googlegroups.com.